3 ms·

For me the biggest plus of UTC is that the values do not jump back in time in spring during the switch to day light saving times. Surely there are tools that al

For me the biggest plus of UTC is that the values do not jump back in time in spring during the switch to day light saving times. Surely there are tools that allow to compare/sort time properly as long as there is TZ in the date, but it is easy to forget to use them especially under the pressure. Then those quick-and-dirty scripts ends up as a permanent utility in production, then on the first of April (or the first of March depending on the country) one spends a lot of time trying to understand why the log merge script fails for the previous months. I really prefer to avoid a chance of that in the first place. Now, as Europe got some sanity and will abandon time shifts the next year, local time as long as as it comes with time zone will be OK. But out of habit I guess I will continue to configure servers to use UTC.

globular-toast 6y ago
The thing is, time itself never jumps back. If you correctly encode your timestamps then you will never experience a discontinuity even if you use a local time zone. In the UK on the 29th March 2020 the time was 00:59:59 GMT and one second later it was 02:00:00 BST. There is no discontinuity there. 02:00:00 BST is 01:00:00 GMT. The mistake is to think the time zone is not part of the value. A "naïve" datetime (as the Python standard library calls it) is simply an incorrect way to store a timestamp. Unfortunately it is Unix time that has a real discontinuity. This happens around leap seconds when Unix time will jump backwards or forwards by a whole number of seconds. This is actually the fault of UTC, though. Leap seconds are an abomination. Unix had the right idea all along which is to just count a number of seconds since an epoch and not worry about the movements of the solar system.