× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.