[krylon]

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.

[logfromblammo]

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.

[dTal]

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.

https://qntm.org/abolish

[logfromblammo]

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.

[krylon]

> 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.

[logfromblammo]

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).

[krylon]

I get your point.

Most of the time (pun not intended), I do not need to worry about the time or date. But on a few occasions I had to, and it gave me a headache every time.

One time (again, pun not intended!), I helped one of our automation engineers who had somehow found out that I know the C programming language and asked me to help him with a problem he was facing: He wanted/needed an input gadget that would allow a worker at the customer site to schedule the cleaning process of the automated machinery in terms of "tomorrow at 3:15am". And then a process had to calculate how far that moment was in the future, sleep for the corresponding duration, then wake up and the the machines to get clean. Except that it had to work across the beginning and ending of DST. Which was not super hard in itself, you either add or subtract an hour from/to the duration you wait, but how do we figure out when the change between DST and normal time occurs? Well, turns out in Germany[0] DST begins on the last Sunday in March at 03:00am (the clock is set to 02:00am) and ends on the last Sunday in October at 02:00am (the clock is set to 03:00am). If all you have is the C standard library (C89!), figuring out if it is the last Sunday of a certain month is surprisingly annoying. Not difficult, but very, very tedious. That made me appreciate the simplicity of C's time_t like no other experience in my life. And I just scratched the tip of the iceberg, with nail file. I can imagine how much fun it gets when different timezones come into play, or divergent definitions of when DST begins and ends.

Your idea of Julian day + millisecond offset sounds beautiful. But I fear it will meet the same enthusiasm as my proposal to convert the metric system from 10^3 to 2^10, i.e. make one kilogram 1024 grams, a metric ton would be 1048576 gram, and so forth.

[0] And probably a lot of other places, but not all of them, because then it would be sorta-kinda consistent, and we cannot have any of that.

[krylon]

I vaguely remember that astronomers sometimes use the Julian calendar for that very reason.

[khedoros1]

https://en.wikipedia.org/wiki/Daylight_saving_time#/media/Fi...

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.

[surement]

> 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.

[lazyasciiart]

It's a source of constant complaints, massive costs and is totally bloody stupid, assuming you're talking about the NSW/QLD border.