Slashdot Mirror
EU Parliament Votes To End Daylight Savings (dw.com)
The European Parliament on Tuesday voted with a large majority to end daylight savings time in the EU by 2021. From a report: Under the proposals, each member state would decide whether to continue with twice-a-year clock changes or stick permanently to summer or winter time. All 28 member states would need to inform the European Commission of their choice ahead of the proposed switch, by April 2020. They would then coordinate with the bloc's executive so that their decisions do not disrupt the functioning of the single market.
DST was created to save energy
Which makes no sense at all. Once you're in winter, you use artificial lighting before dawn and after sunset. It's been that way since before we had gas lighting.
Technically, GMT is NOT the same as UTC. There are actually three different standards... GMT, UTC, and TAI.
They differ because the precise length of an orbital & rotational year is neither 100% consistent nor predictable.
GMT is defined by solar noon at the Greenwich Observatory in London. If observation reveals that we've wobbled by a few milliseconds, GMT changes to reflect that. It sounds nice in theory, but 99.999% of use cases honestly don't give a fuck whether solar noon at Greenwich happens a few hundred milliseconds (or entire seconds) early or late.
TAI is kind of like Unix time, except it has much greater precision. It defines a second as a precise number of cesium-137 decay periods, a year as a precise number of seconds, and counts both as an offset from its starting point. TAI currently deviates from GMT by ~32 seconds.
UTC was envisioned as a compromise between GMT and TAI. It adds and removes seconds to ensure that UTC's noon falls within a half second of Greenwich solar noon. It's also a royal pain in the ass to deal with, because unlike TAI, UTC is a historical moving target. 9:47:42 July 18, 1997 UTC is NOT precisely 8 years before 9:47:42 July 18, 2005 UTC (even accounting for leap year gymnastics), because a couple of seconds were added as well
UTC makes a mess of things like timestamped logs, the same way DST does... but worse, because most people using UTC for timestamps are doing it PRECISELY to avoid the DST timestamp problem, and have no idea that "leap seconds" even EXIST until the first time they get burned by it.
UTC-vs-TAI was exacerbated by the sudden popularity of using internet time protocol (NTP) to automatically set clocks on computers. In the past, people set the time, and let it go until they manually updated it at their own convenience. Leap seconds were rare to begin with during that era, and a second or two gain or loss when the computer got rebooted was lost in the greater disruption of the reboot itself.
Fast forward to sometime around 2006, when UTC-via-NTP had become commonplace, and a leap second occurred, Linux computers all automatically observed it, and all hell broke loose when software that assumed that "UTC" behaved like TAI found itself with 2 seconds' worth of logged activity bearing the same timestamp (and often, undefined weirdness if computations involving milliseconds were involved on computers that did 64-bit timekeeping).
As I understand the "Linux" problem, programmers want TAI-like behavior, but POSIX compliance explicitly requires UTC... switching Linux to TAI would require changes to POSIX to allow timestamps to unambiguously indicate whether they're UTC or TAI, and the current 32-second difference is too big to just sweep under a rug and ignore. So instead, we have a complicated system where computers use NTP to sync up to TAI, then the OS converts TAI to UTC and adds/removes leap seconds before exposing it as the leap-second-mangled offset from midnight January 1, 1970 for consumption by programs that don't actually CARE about the precise moment of solar noon @ Greenwich.
The proposed solution is almost worse... ending leap seconds in UTC (to avoid rewriting POSIX & everything it dictates, causing YEARS of insidious bugs in the process), and inventing a FOURTH standard to do what UTC currently does & keep astronomers happy.
Compounding matters even more is disagreement about how to handle the leap seconds we already have. If UTC retroactively wipes them out, we're back to the problem of ambiguity with "UTC" timestamps between the 1980s and present... no way to indicate whether it's a "legacy" UTC timestamp or a "revised" one. If it doesn't, we'll still have to deal with those legacy timestamps in perpetuity.
The net result is that we're likely stuck with UTC and dealing with leap seconds in Linux for at least another decade or two. My guess is that POSIX will be left alone, UTC will eventually stop adding leap seconds (but leave the existing ones as-is), and they'll come up with a new standard for Astronomers to take the place of UTC.
If you were right, it would cause the end of all rush hour traffic congestion, which would be wonderful.
But back in the real world, most businesses are going to set their hours to be daylight hours since that's when their customers and employees will want to be awake. And back in the real world every business already decides for themselves what their hours are. Many people start work at 7, 8, 9am with no real dominant standard starting time. People talk as "9 to 5" were a standard, but the mean work start time is actually 8:18 (in USA+Europe, source). Which is why it's really more like rush 3 hours instead of rush hour. Clock time really has zilch current influence on when employers set their working hours right now, it would not change if we went to UTC.
This space intentionally left blank