On Mar 12, 2014, at 4:42 AM, Mehant Baid <[email protected]> wrote:
> >> On March 4, 2014, 4:49 p.m., Venki Korukanti wrote: >>> exec/java-exec/src/main/codegen/templates/DateFunctions.java, line 48 >>> <https://reviews.apache.org/r/18055/diff/2/?file=492099#file492099line48> >>> >>> What about comparing timezone for TimeStamp? are we expecting lhs and >>> rhs to have same timezone or is it compared somewhere else? > > Irrespective of the timezone, internally we always store milliseconds in UTC. > This is why we can compare any two timestamps in different timezones without > doing any conversion. If you are complying with the SQL spec, your timestamp values have no timezone. Not UTC. Not local time. Not system time. None whatsoever. So a value of 0 means ‘1970-01-01 00:00:00’. Whether that is UTC (or any other timezone) is up to whoever is using the timestamp. Note that if you put this inside a java.sql.Timestamp, the toString() will attempt to print the value in local time, and therefore people in different timezones & locales will see a different toString() value. Just ignore what the JDK is doing. When the value goes into or out of the system using JDBC, there is an implied translation to/from the timezone of the JDBC client. Some of the JDBC calls have a Calendar object to specify the timezone. Sorry to be pedantic, but I’ve been through many painful hours trying to get SQL datetime values working. There is a big difference between UTC and no timezone. Julian
