Update documentation for parametric TIME WITH TIME ZONE #5316#7912
Update documentation for parametric TIME WITH TIME ZONE #5316#7912electrum merged 5 commits intotrinodb:masterfrom
Conversation
|
Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please submit the signed CLA to cla@trino.io. For more information, see https://github.com/trinodb/cla. |
|
FIxes #5316 |
|
CLA has been submitted via email @martint |
| Time zones are expressed as the numeric UTC offset value. | ||
|
|
||
| Example: ``TIME '01:02:03.456 America/Los_Angeles'`` | ||
| Example: ``TIME '01:02:03.456 -08.00'`` |
There was a problem hiding this comment.
This doesn't seem to work. This works though TIME '01:02:03.456 -08:00'
Same in the other example.
There was a problem hiding this comment.
Got it! Will make the updates.
| Time zones are expressed as the numeric UTC offset value. | ||
|
|
||
| Example: ``TIME '01:02:03.456 America/Los_Angeles'`` | ||
| Example: ``TIME '01:02:03.456 -08.00'`` |
|
|
||
| Time of day (hour, minute, second, millisecond) with a time zone. | ||
| Values of this type are rendered using the time zone from the value. | ||
| Time zones are expressed as the numeric UTC offset value. |
There was a problem hiding this comment.
Lets change this to our default example setup that has the sql query and the output as comment so you can actually cut and paste to try
Time zones are expressed as the numeric UTC offset value::
SELECT TIME '01:02:03.456 -08.00';
== 1:02:03.456-08:00
There was a problem hiding this comment.
@mosabua Is the query meant to have the : instead of the . ? Or just the output?
| type are rendered using the time zone from the value. | ||
|
|
||
| Example: ``TIMESTAMP '2001-08-22 03:04:05.321 America/Los_Angeles'`` | ||
| Example: ``TIMESTAMP '2001-08-22 03:04:05.321 -08.00'`` |
Updates as per requested changes
|
Ideally squash the commits into one commit, but this is good essentially. |
|
|
||
| Example: ``TIME '01:02:03.456 America/Los_Angeles'`` | ||
| SELECT TIME '01:02:03.456 -08:00'; | ||
| == 1:02:03.456-08:00 |
There was a problem hiding this comment.
I am so sorry @meggpie .. I messed up. it should be -- not ==
can you please fix
|
@meggpie did you want to fix this up as requested? |
|
@mosabua yes, it's on my to-do list for today! |
|
@mosabua I made the changes but I'm stull trying to figure out how to squash the commits, sorry |
|
you need to do a git rebase of the last three commits and then a force push Something like this https://stackoverflow.com/questions/5189560/squash-my-last-x-commits-together-using-git ping me on trino slack if you need live help |
|
Thanks! |
| Instant in time that includes the date and time of day with ``P`` digits of | ||
| precision for the fraction of seconds and with a time zone. Values of this | ||
| type are rendered using the time zone from the value. | ||
| Time zones are expressed as the numeric UTC offset value:: |
There was a problem hiding this comment.
This turned out to be understood as indicating that Trino supports numeric offset zones, but not named zones.
see trinodb/trino-python-client#229 (comment) cc @jhlodin
we need to improve the wording to clarify named zones are supported
cc @mosabua
There was a problem hiding this comment.
Probably we need to mention this separately both TIME and TIMESTAMPTZ since TIME doesn't support named zones (since they don't make sense there) while TIMESTAMPTZ does.
There was a problem hiding this comment.
Whatever supports timezone should be consistent .. is that the case now.. I am not sure to be honest.
There was a problem hiding this comment.
It cannot be consistent since TIME has no concept of named zones. What does TIME '01:01:01' America/Los_Angeles mean? Depending on what day it was America/Los_Angeles can mean different things.
We need to explicitly make it more clear that TIME with timezone supports only offsets and not named zones while TIMESTAMP with timezone supports both named offsets and numbered offsets.
There was a problem hiding this comment.
What does
TIME '01:01:01' America/Los_Angelesmean?
This is a wrong question to ask. We don't need to go into details why.
TIME has no concept of named zones.
yes, it does not.
There was a problem hiding this comment.
time(p) with time zone is in the SQL standard. It's defined as a time with a time zone displacement containing an hour and a minute component in the range -14:00 to +14:00. That's the only concept of timezones supported by the specification, even for the timestamp(p) with time zone type. Support for political time zones is an extension to the standard.
There was a problem hiding this comment.
So .. to simplify for users and consistency .. should we remove the support for political time zones everywhere?
There was a problem hiding this comment.
No, political timezones are useful and necessary for timestamp(p) with time zone.
There was a problem hiding this comment.
Okay ... I think we have enough info now to run with a doc update PR .. @jhlodin will submit soon.
9 participants
Updated description and example timezones to numeric format.
