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


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.


Nicolas Mailhot

----- Mail original -----
De: "Joe Touch" <>
À: "Wesley Oliver" <>, "nicolas mailhot" <>
Cc: "Jim Reid" <>,
Envoyé: Samedi 18 Mars 2017 02:00:20
Objet: Re: 2017-03-06- UTC, TImeZone, DayLight Saving Shifts, Enconding

Hi, all,

On 3/7/2017 12:20 PM, Joe Touch wrote:
> Hi, all,
> ...
> However, I'm pulling together a draft on the this issue in order to
> cache this information for future users.
The queue has closed, but I've completed an 00 draft here:

I'd be interested in feedback and further discussion, though I suspect
there is probably a better list for that (any suggestions?)


Received on Saturday, 18 March 2017 09:20:41 UTC