Hey Julian,
I think there is a slight naming mismatch I might've caused which can be
fixed. I've introduced a data type called "DateTime" which is exactly
what you are referring to (its a point in time represented by long
milliseconds since epoch *with no time zone information*).
There is another data type called "TimeStamp" which stores two things
(1. long milliseconds since epoch (in utc) 2. time zone). This is
similar to the data type "Timestamp with timezone" in Oracle or
"DateTimeOffset" in Sql server. What do you think about adding support
for this data type in Optiq?
Thanks
Mehant
On 3/12/14, 11:15 AM, Julian Hyde wrote:
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
