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.

Comments

Yay but nay

[bjoeg]

So we might finally end this, but only repeat history and head back into the chaos.
One Thing was that DST was created to save energy, but was not adopted by all countries in the beginning. It was only back in 1996 whole of EU got DST standardized so all member would change clocks on the same dates.

But now we are heading back into the chaos, where each member can decide which ever time they will implement. So we are back to pre-1996.

Re:Yay but nay

[gizmo71]

The problem is not the times you do stuff - it's that for half the worl, the date would suddenly change in the middle of the day. "It's my birthday! But only from 1pm today to 1pm the next day" fails a basic sanity check - the notion of 'today' becomes bunk.

Re: Yay but nay

[Miamicanes]

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.

Re: Permanent DST is a mistake as well.

[Chris Mattern]

3 am or 4 am sunrise hardly makes a difference if you want to sleep until 7 or 8 am. Get some good curtains if the light bothers you.

The problem isn't so much that the sunlight interfers with your sleep, as you waste daylight hours asleep and then are active after sunset in the dark. It's better if you get up earlier and have more daylight at the end of the day, hence, daylight savings time. I've particularly noticed this advantage as I've gotten older and my night vision has deteriorated; I very much appreciate having daylight to see by in the evenings.