Re: 2017-03-06- UTC, TImeZone, DayLight Saving Shifts, Enconding

Hi, Nicolas,

I agree that the advice is buried and maybe a little less direct than
would be useful.

This issue began twice on the IETF list from suggestions that "we could
do better", especially in avoiding discontinuities or nonuniformity. The
point of this doc is that there's no short-cut.

So here's a summary of what I think should be up front (with a few
paragraphs). Can you let me know if that's what you were expecting?



- system designers SHOULD NOT invent their own time scale because every
gain that might be considered will be offset by significant pain when
coordinating with others later
- there are no shortcuts for dates compared across different systems -
maintaining those dates requires monitoring external info (leap seconds
and time zones), thus:
    - dates SHOULD use UTC in most cases because it is the basis of all
civil time
    - in general, a date system SHOULD maintain related information
about leap-seconds and time zones
            - a date system that requires accurate interval calculation
MUST maintain that information
    - applications that interact with users SHOULD record the location
of a date (e.g., as a time zone)
    - dates MAY use TAI for applications that need to optimize for
interval calculations
    - dates MAY use local time (UTC offset by the local time zone) for
applications that need to optimize for interacting with users


On 3/18/2017 2:20 AM, wrote:
> Hi,
> While the explanations are nice to have, the document does not really answer the problems of 99,99 % of implementers.
> They feel UTC is unfamiliar and hard, they are exposed to a slew of legacy non-standard ways of representing time, they are confused by the number of possible datetime representations, they are confused by variations in local time representations, they are confused by legacy custom time representations in their existing middleware and apps, so they tend to adopt some variation of those legacy conventions, of even cook their own, thinking they will be able to convert them to something else when the time comes to interoperate, and when they'll have made sense of all of this. And then when they have made a thorough mess of their datetime datastore they shout for help, because you know UTC is hard, the proof being they made a mess of things.
> The document as it stands buries them under yet more options before offering any advice (and tentative at most).
> The basic fact is that right now (state of the art may evolve) the only sane option except for specialized apps is to store all timestamps in UTC, timezone Z, w3c or RFC 3339
>  iso 8601 profile, no iso 8601 funky compat options. And convert in the UI in the presentation layer to local time. And keep the local TZ database up to date. And use NTP.
> That should be the first paragraph of the document (with a few examples). That would actually help people out of their datetime messes. I know it's not satisfying from a theoretical point of view, it's not innovative, but most implementers are that confused today. The trains here do stop each year for an hour at DST time, the train companies are afraid some automaton somewhere won't cope with the hour change, caring about leap seconds is decades away, and they are one of the few big businesses with yearlong 24/24 activity
> Then, for the very small minority that needs better than UTC, the rest of the explanations are welcome. But please not before a very firm and simple SHOULD UTC that will solve most actual problems. Otherwise the document does not help at all, and is counter-productive.
> Regards,

Received on Saturday, 18 March 2017 15:03:26 UTC