TimeZone discrepancy in mysql and java

Question

I have a query in mysql which compares 2 dates like this

convert_tz(updatedDate,\'+05:30\',\'-05:00\') < ?

the convert function returns

Answer 1

Timezone information is not applied to dates/times unless you either set useTimeZone=true in your connection URL. You can use the getTimestamp() method also, which take calendars as an argument.

Answer 2

Without seeing the values that are matching on the second query and not on the first, it's hard to be absolutely certain. But one thing to keep in mind is that a time zone is not the same as an offset. Please read "TimeZone != Offset" section of the TimeZone tag wiki.

For example, you say you are converting to the America/New_York time zone. This zone is sometimes in UTC-05:00 (for Eastern Standard Time), and sometimes in UTC-04:00 (for Eastern Daylight Time). It is entirely possible that some of your data is being picked up because of the -4 offset in effect during daylight savings time.

When you hardcode to the -5 offset, you are not taking any time zone rules into consideration. Which would explain the discrepancy.

Answer 3

Background: A surprisingly common--and big--misconception shared by even brilliant programmers is the notion that stored time stamps (in your database, Date, Calendar, Timestamp, et al) somehow have time zone information. They do not. A time stamp (up until Java 8, anyway) is stored as the number of milliseconds since midnight on 1 Jan 1970 UTC. End of sentence. The only thing setting the time zone does is provide enough information to the computer to convert that time stamp to a human readable format, and vice versa.

Answer: When you suspected that this was a time zone problem, you were right. But the code you used to try to verify this also has a problem:

end.setTimeZone(TimeZone.getTimeZone("America/New York"));
pst.setTimestamp(1, new java.sql.Timestamp(end.getTimeInMillis()));

That setTimeZone statement has no effect on the time stored in end, because the time has already been set. It would only have had an effect if you stored the time afterwards, and then only if you used one of Calendar's methods which converted the time from a human readable format (and not setTimeInMillis).

When you use getTimeInMillis to pass the time stamp to your prepared statement, you're retrieving the time stamp directly. Since you're not converting it to a human format, once again the time zone information is ignored.

When you try

SimpleDateFormat sdf=new SimpleDateFormat("yyyy-MM-dd hh:mm:ss");
end.setTime(sdf.parse("2012-10-01 00:00:00"));
pst.setTimestamp(1, new java.sql.Timestamp(end.getTime()));

and

pst.setTimestamp(1, new java.sql.Timestamp(octDate.get(Calendar.YEAR)-1900,octDate.get(Calendar.MONTH),octDate.get(Calendar.DATE),octDate.get(Calendar.HOUR),octDate.get(Calendar.MINUTE),octDate.get(Calendar.SECOND),0));
pst.setTimestamp(2, new java.sql.Timestamp(end.get(Calendar.YEAR)-1900,end.get(Calendar.MONTH),end.get(Calendar.DATE),end.get(Calendar.HOUR),end.get(Calendar.MINUTE),end.get(Calendar.SECOND),0));

things appear to work because you are now using methods which convert to/from a human readable format, and therefore the specified time zone information is used. However, this is only covering up the real problem. The real issue is that the time was improperly converted when you parsed it from endString. That is, the time zone that endString was expressed in does not match the time zone set in df1 at the time the date was parsed.

SHORT ANSWER: before this line:

end.setTime(df1.parse(endString));

You need to:

• Figure out what time zone the time in endString was expressed in.
• Set df1 and not end to that same time zone. Since df1 is the thing that is converting the date from human format, it's that time zone information that's used.

Cheers!

Answer 4

Which value is returned from your TimeZone.getDefault().getID() and from MySQL default time zone?

BTW you can try using an utility like this one to convert datetime across timezones:

public Calendar convertDateToServerTimeZone(Date dateTime, String timeZone) {
    Calendar userDefinedTime = Calendar.getInstance();
    userDefinedTime.setTime(dateTime);
    if(!TimeZone.getDefault().getID().equalsIgnoreCase(timeZone)) {
    System.out.println        ("original defined time: " + userDefinedTime.getTime().toString() + " on tz:" + timeZone);
    Calendar quartzStartDate = new GregorianCalendar(TimeZone.getTimeZone(timeZone));
    quartzStartDate.set(Calendar.YEAR, userDefinedTime.get(Calendar.YEAR));
    quartzStartDate.set(Calendar.MONTH, userDefinedTime.get(Calendar.MONTH));
    quartzStartDate.set(Calendar.DAY_OF_MONTH, userDefinedTime.get(Calendar.DAY_OF_MONTH));
    quartzStartDate.set(Calendar.HOUR_OF_DAY, userDefinedTime.get(Calendar.HOUR_OF_DAY));
    quartzStartDate.set(Calendar.MINUTE, userDefinedTime.get(Calendar.MINUTE));
    quartzStartDate.set(Calendar.SECOND, userDefinedTime.get(Calendar.SECOND));
    quartzStartDate.set(Calendar.MILLISECOND, userDefinedTime.get(Calendar.MILLISECOND));
    System.out.println("adapted time for " + TimeZone.getDefault().getID() + ": " + quartzStartDate.getTime().toString());
    return quartzStartDate;
    } else {
    return userDefinedTime;
    }
}

I have worked with this function here: Java Quartz-Scheduler across TimeZone

Hope his helps.

Answer 5

Give this a try.

Set timestamp parameter as you are setting now

pst.setTimestamp(1, new java.sql.Timestamp(end.getTimeInMillis()));

.

During database call, JDBC driver may already be converting input date/time values to GMT. So the date value that database is dealing with won't have to take timezones of input date into considerations which may differ from one client to other.

Instead of setting from_tz as '+05:30'

convert_tz(updatedDate,'+05:30','-05:00')

Set from_tz as '00:00'

convert_tz(updatedDate,'00:00','-05:00')