But DST is in summer, isn't it? At least that is what I have been told: In summer, days are so long and start so early that we might as well move the whole day back by an hour, so get up early, finish work early and still have a couple of hours of daylight left.
Full disclosure: I am not a fan of DST, but I do not expect the current situation to change. In Europe, almost(?) all countries use it, so if just Germany (where I live) abolished DST, we would be out of sync with the rest of Europe for half of the year. Dealing with dates and times as a programmer is already confusing enough; if DST was to go, all countries would have to drop it simultaneously, or else the resulting patchwork would be too much of a pain. And I do not see that happening anytime soon.
DST is the civil equivalent of changing the behavior of some electronic hardware by doubling the clock signal instead of reprogramming and re-flashing the firmware. It's simple to do, but is also stupid and inefficient, and causes a lot of obscure unintended consequences later on. I'd actually be fine with converting all time and date records, all calendars, and all clocks to integer Julian Day Number, plus the integer number of milliseconds since mean solar noon at the Prime Meridian, plus another numeric field for greater precision, because there is an enormous advantage to not doing stupid tricks with clocks and time zones. Just count.
You do this at the expense of a huge amount of practical day-to-day functionality of time. Most people want times to be at least roughly synchronised with their day, and would rightly object to your system in the strongest possible terms.
Your link states that UTC is the international standard. Maybe for humans.
Unix time can represent roughly from 1902 to 2038 in 32 bits. That's the usual intermediary between the clusterfork of records in zoneinfo. To convert between time zones, you convert to the simple second count of Unix time, then convert to the target zone.
Much easier to store the time as the simple count and just make the UI do the work to display it in some user-friendly fashion. When the machines communicate to each other, there is no confusion, because they do not carry any assumption baggage regarding time.
We really need to fix time representation before 2038. Julian day plus second count is a decent intermediate step to a time representation that is agnostic to the cycles and orbits of specific planets. The least disruptive end game is probably a 64-bit integer representing a simple count of the number of milliseconds elapsed since the Julian Day epoch.
That would make now about 212383579680000, and we'd have until 9223372036854775807, or about 292 million years from now, to even decide whether to go another 292 million years by making it an unsigned int, or just expand it out to 128 bits, because chip architectures have been able to handle that much for 292 million years already.
The simple count is rather easy to convert into a human readable time. Subtract an epoch constant, then modulo by some cycle-length constants. Adjust by a custom rule set if necessary.
Besides that, why would I want to call Uncle Steve in Melbourne? Why couldn't I just send an asynchronous message to him? That asynchronous message can even include metadata about when I am available for synchronous communications. So yeah, I can "publish my 'waking hours'", as summarily dismissed by that apologia for time zones. I don't know when that was written, but now that every phone can be a computer, as well as a pocketwatch and personal calendar, the built-in assumptions that were necessary beforehand are no longer required.
I don't need to know that people are typically awake in a safe range between 9 AM and 9 PM as expressed in their local time zone. I don't really even need to know when they'll be awake to pick up. I can tell the computer assistant to give their user a message, and the assistant might or might not sound an audible alert that the user has new messages. I don't even really need to publish my own waking hours. If I don't care about that aspect of my privacy, I can let my computer assistant tell other computer assistants when its user is typically receptive to synchronous communication requests, based on usage history. It can advertise my "online" status for me, or lie about it for me, such as if I tell it to say I'm "away", but I'm actually on my phone, playing a few levels of Skinnerbox 5: Revenge of the Lootbox.
> Unix time can represent roughly from 1902 to 2038 in 32 bits.
Uh, several systems have already switched to a 64 bit timestamp that should last for a while. I am relatively certain that OpenBSD and NetBSD have done it, and I vaguely remember Linux doing that, too, but that might be a vague memory or wishful thinking. Other systems probably have switched, too.
That's fine; better than nothing. It still represents times within the span of human history as negative numbers, which sometimes leads to certain kinds of bugs.
Ideally, I'd never have to work with a negative date-time number, because someone always seems to want to check if t > 0 somewhere, and there's always a reason why t could plausibly be a valid negative. Or maybe someone picked some negative t as a sentinel value, and then left the company before I ever got a chance to slap them.
Julian Day is the only kind of time that has never insulted my delicate sensibilities in some way. Maybe that's intrinsic to the type, or maybe it's because those who chose to use it have never done stupid things with time (that I could see).
In areas that are arguably Europe, it looks like Iceland, Kaliningrad Oblast, and Belarus are the places that stick out.
I'm in California; most of Arizona is permanently in daylight savings, and we work with a lot of developers in China and India, which don't observe it. It certainly complicates things, sometimes.
I've done work on my product's logging subsystem before, and especially bugs with recorded times. Dealing with different DST rules is a mess.
> if DST was to go, all countries would have to drop it simultaneously, or else the resulting patchwork would be too much of a pain
There are already countless exceptions to DST and people seem to be doing fine. E.g. in Australia there are two regions in the same time zone where only one has DST, meaning they are out of sync for half the year.
As someone who lives in Arizona myself, it is a bit strange to have (virtually) the rest of the world change their clocks without us... makes scheduling remote meetings difficult, if nothing else. (On the other hand, we don't have to worry about changing our clocks in the first place, so there's that?)
For some extra fun, the Navajo Nation observes DST, and they're _inside_ Arizona.
Full disclosure: I am not a fan of DST, but I do not expect the current situation to change. In Europe, almost(?) all countries use it, so if just Germany (where I live) abolished DST, we would be out of sync with the rest of Europe for half of the year. Dealing with dates and times as a programmer is already confusing enough; if DST was to go, all countries would have to drop it simultaneously, or else the resulting patchwork would be too much of a pain. And I do not see that happening anytime soon.