Hi Calcites, In Druid SQL we have a connection time zone concept; see the mentions of "sqlTimeZone" here: http://druid.io/docs/latest/querying/sql.html. It affects the time zone of any operation involving timestamps, including the interpretation of literals, the behavior of functions like FLOOR and EXTRACT, and the interpretation of Druid's built-in time column (which is stored as 64-bit millisecond-resolution epoch time but is interpreted as a timestamp type in SQL).
This is all well and good, but the issue I'm having now is that Calcite's "SqlLiteral.value" function translates INTERVAL '1' DAY and similar literals into millisecond values. This works fine in UTC but doesn't work in any time zone that has daylight savings time -- since in those zones, not all days are the same length. I don't see a way to work around this without modifying Calcite, since really, INTERVAL '1' DAY and INTERVAL '24' HOUR shouldn't be treated the same, but they are. Fwiw, PostgreSQL has a similar session time zone concept, and it does potentially treat 1 day and 24 hours differently: https://www. postgresql.org/docs/9.2/static/functions-datetime.html So I have a couple of questions. 1) Does it make sense to modify Calcite to support this use case? 2) If "yes" then how? The simplest thing I can think of is changing INTERVAL_DAY_TIME literals to store their values as Joda Periods ( http://joda-time.sourceforge.net/apidocs/org/joda/time/Period.html) or similar, rather than as a number of milliseconds, and updating downstream code appropriately. This wouldn't be backwards compatible; is that ok? If it's not ok, maybe it should be behind an option? Thanks as always. Gian
