On Mon, Feb 3, 2020 at 3:20 PM Rob Berendt <rob@xxxxxxxxx> wrote:
Is this a valid timestamp (if you're in an area following DST)?
values timestamp('2020-03-08-02.15.00');
I don't know if it is, but it shouldn't be.
When running
values timestamp('2020-03-08-01.15.00') + 1 hour;
Should the answer be 2020-03-08-02.15.00 or 2020-03-08-03.15.00?
What if you're calculating a recipe for production?
The answer *should* be 2020-03-08-03.15.00. Again, I can't say what
the system will actually give you.
As always, it's preferable to do all time and date arithmetic using
UTC, and only switch to local time as needed for input and output. In
other words, local time should be treated as a formatting issue,
analogous to *USA, *EUR, etc. for date formatting.
For me, the more interesting question is how to handle input and
output using local time during the extra hour in the fall. The missing
hour in spring is unambiguous. Without forcing people to enter or read
UTC, how do you differentiate the first 2020-11-01-01.15.00 from the
second one?
(My answer would be: You don't. On output, you just show the correct
local time, and it's the reader's responsibility to infer which
instance it is. On input, you disallow entry of anything in the
ambiguous period. Or, if you're in an industry which *must* be able to
enter all valid values for the time (for example, a hospital), then I
would probably provide some kind of mandatory-entry field to
differentiate the local times. I am guessing it would be too much to
force users to enter UTC times directly themselves.)
John Y.
As an Amazon Associate we earn from qualifying purchases.