Added section explaining legacy and new timestamp#12146
Added section explaining legacy and new timestamp#12146findepi wants to merge 1 commit intoprestodb:masterfrom findepi:findepi/master/added-section-explaining-legacy-and-new-timestamp-e7fc54
Conversation
There was a problem hiding this comment.
https://dictionary.cambridge.org/dictionary/english/semantics suggests semantics is uncountable
There was a problem hiding this comment.
Let's avoid using "enable" here for the new semantics since the config property is inverted. How about
by configuring them globally or on a per-session basis
There was a problem hiding this comment.
In other documentation, like Properties Reference or release notes, we just say "config property" or "configuration property". Also, let's be more explicit about what true/false means.
The legacy semantics can be enabled using the ``deprecated.legacy-timestamp``
config property. Setting it to ``true`` (the default) enables the legacy semantics,
whereas setting it to ``false`` enables the new semantics.
There was a problem hiding this comment.
Additionally, they can be enabled or disabled on per-session basis
with the ``legacy_timestamp`` session property.
There was a problem hiding this comment.
small edit: on a per-session basis
There was a problem hiding this comment.
Could we simplify these to year, month, day, hour, minute, second?
I'm not sure that "of era", "of year", etc., add any value (it seems obvious what they mean, and I can't think of any other reasonable alternative interpretation)
There was a problem hiding this comment.
I think these terms follow terminology that can be found in Java Time and Joda Time.
-
java.time.LocalDateTime#getDayOfYear -
java.time.LocalDateTime#getDayOfMonth -
java.time.LocalDateTime#getDayOfWeek -
org.joda.time.LocalDateTime#getDayOfYear -
org.joda.time.LocalDateTime#getDayOfMonth -
org.joda.time.LocalDateTime#getDayOfWeek
Joda LDT has 3 methods getYear*, but Java Time's LDT has just one getYear.
I can remove these OF .. from here. Please decide.
There was a problem hiding this comment.
These lines that wrap on GitHub are too long, please wrap to ~80 characters.
There was a problem hiding this comment.
Let's use American rather than British formatting:
For example, with a session start time of March 1, 2017:
Or use ISO format:
For example, with a session start time of 2017-03-01:
There was a problem hiding this comment.
Does the session time zone matter for the example below?
There was a problem hiding this comment.
It does not. However, in legacy semantics, session time (instant when transaction started) matters.
There was a problem hiding this comment.
Can we explain what is different between the new Presto semantics and what is specified in the SQL standard?
Or is this really trying to say that it's not possible to follow the standard when using political time zones because the standard does not have them?
There was a problem hiding this comment.
The latter. Let's refactor this paragraph when we remove political zones from TIME.
There was a problem hiding this comment.
We use "see also" in the docs. I picked that up from PostgreSQL, but it seems to be the proper way of writing citations.
There was a problem hiding this comment.
Should we name this "timestamp" rather than "time"?
|
@electrum thanks for review. |
findepi
deleted the
findepi/master/added-section-explaining-legacy-and-new-timestamp-e7fc54
branch
5 participants
No description provided.