Invalid Date exception | SOLR - exception

I am getting an invalid date string exception when searching for indexType:2013-06-26T18:30:00Z TO NOW.
The Stack trace I get is as follows:
Nov 18, 2013 10:19:18 AM org.apache.solr.common.SolrException log
SEVERE: org.apache.solr.common.SolrException: Invalid Date String:'2013-06-26T18'
at org.apache.solr.schema.DateField.parseMath(DateField.java:165)
at org.apache.solr.schema.TrieField.readableToIndexed(TrieField.java:301)
at org.apache.solr.schema.TrieField.toInternal(TrieField.java:309)
Solr Version: 3.5.0.2011.11.22.14.54.38
Although when I look in the index, it has the date value in absolutely the same pattern, so it is a bit strange.
Thanks in advance.

The query parser interprets your query as
indexType | 2013-06-26T18
defaultSearchField | 30
defaultSearchField | 00Z
defaultSearchField | TO
defaultSearchField | NOW
try instead
indexType:[2013-06-26T18:30:00Z TO NOW]
more on Solr query syntax here.

Well, first of all the easiest, and I guess the proper way, is to set the date range within squared parenthesis []:
indexType:[2013-06-26T18:30:00Z TO NOW]
Another way is the use of escape sequence before each colon like this:
indexType:2013-06-26T18\:30\:00Z TO NOW

Related

I get an error : MSG529, Level 16, State 2, Line 116 Explicit conversion from data type time to int is not allowed

Please assist me here. I get error:
Msg 529, Level 16, State 2, Line 116
Explicit conversion from data type time to int is not allowed.
When I try to convert time column into int.
select convert( int , TrainDirectionCode) from [Rail_Equipment_Accident_Incident_Data 2]
I need to get this Extra long column to show just 1 or 2 or 3 or 4.
Currently I have format: 04:00:00.0000000
You can use the hour() function to extract only the hour from your time column.
First of all, this looks a lot more like SQL Server than MySQL...
In either case, there's no direct conversion from a Time value to an Int value. After all, what integer does 04:00:00.0000000 represent? 4? 400? 14,400? Why?
If this is indeed SQL Server then it sounds like what you're looking for is the DATEPART function to extract a specific "part" of the value. Something like this:
SELECT DATEPART(hour, [TrainDirectionCode]) FROM [Rail_Equipment_Accident_Incident_Data 2]

Mysql convert string to time

Currently, my start_time column was string type.
I want to convert 8:00 AM to 8:00:00 using MySQL.
I have tried like this but it didn't work SELECT STR_TO_DATE('8:00 AM', '%h:%i %p')
Since you are using Laravel, I recommend to use Carbon.
Carbon is an inherited php class from DateTime what makes you able to format times in any way you want and like.
Related to your question:
SELECT STR_TO_DATE("08:00 AM", "%h:%i %p"); // output: 08:00:00
Works fine, so there is something else that causes your problem, but you are giving us not enough information to help you further.
What db are you using?
What version?
what outpout do you get?
etc.

Google Apps Script - MySQL data import using JDCB does not work with Date 0000-00-00 [duplicate]

I have a database table containing dates
(`date` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00').
I'm using MySQL. From the program sometimes data is passed without the date to the database. So, the date value is auto assigned to 0000-00-00 00:00:00
when the table data is called with the date column it gives error
...'0000-00-00 00:00:00' can not be represented as java.sql.Timestamp.......
I tried to pass null value to the date when inserting data, but it gets assign to the current time.
Is there any way I can get the ResultSet without changing the table structure?
You can use this JDBC URL directly in your data source configuration:
jdbc:mysql://yourserver:3306/yourdatabase?zeroDateTimeBehavior=convertToNull
Whether or not the "date" '0000-00-00" is a valid "date" is irrelevant to the question.
"Just change the database" is seldom a viable solution.
Facts:
MySQL allows a date with the value of zeros.
This "feature" enjoys widespread use with other languages.
So, if I "just change the database", thousands of lines of PHP code will break.
Java programmers need to accept the MySQL zero-date and they need to put a zero date back into the database, when other languages rely on this "feature".
A programmer connecting to MySQL needs to handle null and 0000-00-00 as well as valid dates. Changing 0000-00-00 to null is not a viable option, because then you can no longer determine if the date was expected to be 0000-00-00 for writing back to the database.
For 0000-00-00, I suggest checking the date value as a string, then changing it to ("y",1), or ("yyyy-MM-dd",0001-01-01), or into any invalid MySQL date (less than year 1000, iirc). MySQL has another "feature": low dates are automatically converted to 0000-00-00.
I realize my suggestion is a kludge. But so is MySQL's date handling.
And two kludges don't make it right. The fact of the matter is, many programmers will have to handle MySQL zero-dates forever.
Append the following statement to the JDBC-mysql protocol:
?zeroDateTimeBehavior=convertToNull&autoReconnect=true&characterEncoding=UTF-8&characterSetResults=UTF-8
for example:
jdbc:mysql://localhost/infra?zeroDateTimeBehavior=convertToNull&autoReconnect=true&characterEncoding=UTF-8&characterSetResults=UTF-8
Instead of using fake dates like 0000-00-00 00:00:00 or 0001-01-01 00:00:00 (the latter should be accepted as it is a valid date), change your database schema, to allow NULL values.
ALTER TABLE table_name MODIFY COLUMN date TIMESTAMP NULL
As an exteme turnaround, when you cannot do an alter to your date column or to update the values, or while these modifications take place, you can do a select using a case/when.
SELECT CASE ModificationDate WHEN '0000-00-00 00:00:00' THEN '1970-01-01 01:00:00' ELSE ModificationDate END AS ModificationDate FROM Project WHERE projectId=1;
you can try like This
ArrayList<String> dtlst = new ArrayList<String>();
String qry1 = "select dt_tracker from gs";
Statement prepst = conn.createStatement();
ResultSet rst = prepst.executeQuery(qry1);
while(rst.next())
{
String dt = "";
try
{
dt = rst.getDate("dt_tracker")+" "+rst.getTime("dt_tracker");
}
catch(Exception e)
{
dt = "0000-00-00 00:00:00";
}
dtlst.add(dt);
}
I wrestled with this problem and implemented the URL concatenation solution contributed by #Kushan in the accepted answer above. It worked in my local MySql instance. But when I deployed my Play/Scala app to Heroku it no longer would work. Heroku also concatenates several args to the DB URL that they provide users, and this solution, because of Heroku's use concatenation of "?" before their own set of args, will not work. However I found a different solution which seems to work equally well.
SET sql_mode = 'NO_ZERO_DATE';
I put this in my table descriptions and it solved the problem of
'0000-00-00 00:00:00' can not be represented as java.sql.Timestamp
There was no year 0000 and there is no month 00 or day 00. I suggest you try
0001-01-01 00:00:00
While a year 0 has been defined in some standards, it is more likely to be confusing than useful IMHO.
just cast the field as char
Eg: cast(updatedate) as char as updatedate
I know this is going to be a late answer, however here is the most correct answer.
In MySQL database, change your timestamp default value into CURRENT_TIMESTAMP. If you have old records with the fake value, you will have to manually fix them.
You can remove the "not null" property from your column in mysql table if not necessary. when you remove "not null" property no need for "0000-00-00 00:00:00" conversion and problem is gone.
At least worked for me.
I believe this is help full for who are getting this below Exception on to pumping data through logstash
Error: logstash.inputs.jdbc - Exception when executing JDBC query {:exception=>#}
Answer:jdbc:mysql://localhost:3306/database_name?zeroDateTimeBehavior=convertToNull"
or if you are working with mysql

Rails and MySql datetime behaviour

I just noticed something odd in my Rails application.
When I update a DateTime column with a random value like below code, it automatically generates a wrong DateTime and saves it instead of NULL.
user = AdminUser.last
data = {last_sign_in_at: "1234568!"}
user.update_attributes(data)
And it generates a query like below:
UPDATE `admin_users` SET `last_sign_in_at` = '1234-01-01 04:56:02', `updated_at` = '2018-01-24 21:27:50' WHERE `admin_users`.`id` = 3
Where is that odd DateTime value coming from ? And interestingly it works with that specific random value. Not with something like "invalid!" and "1234568!" .
So is this something to do with MySql or Rails query generation ?
Maybe I am not aware of such things in database, as it is not something I work with regularly .
It looks like rails use Time library to convert your 1234568! and if you try that in rails console like Time.zone.parse('1234568!') you get back a Time object Sun, 01 Jan 1234 00:00:00 UTC +00:00 but if you try to do a Date.parse(1234568!) it throws you an ArgumentError: invalid date error so maybe you can parse using date to avoid that.

Ruby active record inserting datetime instead of time in mysql

Rails Active Record save uses datetime in insert query although the datatype is time in mysql and time is set in model before saving
mysql schema:
rtime time DEFAULT NULL
ActiveRecord model: Abc
abc = Abc.new {'rtime'=> '18:23 PM'}
abc.save!
corresponding mysql query generated by active record:
insert into abces (rtime) values('2000-01-01 18:23:00');
Later in mysql only the time is stored and date is sliced off, and a warning is also generated.
+-----------------------+
| rtime |
+-----------------------+
| 18:23:00 |
+-----------------------+`
Why is the date appended with time while mysql insertion?
Rails version: 3.2.16
Looks like ActiveRecord often falls back to a DateTime object when assigning a Time in Rails 3+: https://github.com/rails/rails/blob/3-2-stable/activerecord/lib/active_record/attribute_assignment.rb#L130
There's some documentation on the conversion method here: http://apidock.com/rails/Time/time_with_datetime_fallback/class. Also, there's a comment that hints at this on line 180 of the same file: # we instantiate Time object and convert it back to a date thus using Time's logic in handling invalid dates
Thus it seems Rails 3 often treats Time objects as though they were DateTimes, which explains the odd insert query you're seeing. The behavior seems to be changed in Rails 4 so upgrading may resolve the issue.
In any case the date values seem to simply get truncated by MySQL hence the warning, but the stored time seems correct to me.
Finally, do you need a timezone for this time?