adamhooper commented on issue #686:
URL:
https://github.com/apache/arrow-datafusion/issues/686#issuecomment-884445745
@alamb Could you please write example results? Maybe centered around
1970-01-01 so the math is trivial?
`TO_TIMESTAMP('1970-01-01+01:00')` => will this produce
`-3_600_000_000_000`? `0`? Or `+3_600_000_000_000`? (I would expect
`-3_600_000_000_000` regardless of second param, because why would the `+01:00`
be in the input string otherwise....)
I think allowing `'UTC'` as a second parameter seems not-terrible. (That's a
compliment ;).) It's backwards-compatible and not too confusing. You could even
plod towards setting it by default, across major versions, by adding a
`'local'` magic default value; deprecating NULL; switching the default to
`'UTC'`; deprecating the param entirely; then finally dropping the param. I
think allowing _other_ (non-`'UTC'`) values would be confusing to a
doc-defeating extent (and of questionable value, since Parquet doesn't support
other timezones).
`TO_TIMESTAMP('1970-01-01')` => you wrote "local time" in two examples, and
I think that's ambiguous because it defines the result in terms of the result.
Do you mean the client's localtime? The server's localtime? The session
localtime? Or "calendar-date-plus-wall-time" -- e.g., "nanos since unix epoch
until 1970-01-01 UTC"? So `TO_TIMESTAMP('1970-01-01')` would always give `0`
and `TO_TIMESTAMP('1970-01-01', 'UTC')` would always give `0`?
`TO_TIMESTAMP('1970-01-01+01:00', 'UTC')` => `-3_600_000_000_000`?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
