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

Hi,

Sorry, but  the following is not true except for the most basic system

> People assume they can log in UTC and then make the round trip 
> back again at some arbitrary point in the future but it doesn't always 
> work out so well. At least by storing the local time we are storing the 
> time we want to see on that clock on the wall.

People assume they can log in local time and reconciliate later. But that does not work in actual life. 

When you store in UTC as first step you avoid problem with ambiguous DST hour overlap. The only thing app writers need to remember is that the datetime is in UTC, with simple uniform and clear local-to-UTC on input, and UTC-to-local on display rules. All datetime comparisons and computations happen without offset. Most apps manage this just fine. Errors are easy to identify, the offset from UTC is generally sufficient for them to be glaring. When one source is misconfigured, it's relatively easy to backdate its data to the correct offset because the errors have not propagated past the initial storage UTC conversion (and, really, it's not different from one faulty clock, which operators understand just fine).

When you store in local time apps need to take into account sources that may or may not be on the same offset (remote, local, past, present), that may or may not be the same offset that will be outputed. So every single operation must not forget that every input and every output potentially uses a different offset. You have tricky local-to-local comparisons (with different meanings of local). You get multiple-conversion problems. You get faulty data (hidden by one comparison that masks another, till a correct app is added to the mix). In that context you *will* have mistakes at every step, to such a level I've seen people use the timezone of a neighbouring country that didn't do DST just to purge their systems of problems. A local time system seems easier but I wouldn't trust it my data. I've seen too many expensive failures this way. Local time storage = built-in flackyness.

That's the same reason why conversion from 7bit ASCII-only to local 8bit encodings was such a pit of snakes, to such an extent i18n only really happened when UTF-8 or some sort of unicode was adopted as the interchange and storage standard. Multiple conversions are inherently faulty. Simple to-uniform on input, to-local on disply rules on the other hand work.

People are all too ready to blame their datetime problems on UTC, when one app mishandles them it's the UTC apps problems because "everything would have been fine-and-dandy with good olde local time". When in fact the good olde local time never worked so well, and it's the app that can not manage UTC correctly that needs fixing.


Regards,

-- 
Nicolas Mailhot

Received on Monday, 20 March 2017 09:05:33 UTC