161–170 of 466 posts
Excellent read around the acrobatics of timezone software. It really is quite flexible. It leads me to wonder. If it's all just an automated and finite offset, there's no reason for daylight savings policies to hew to 60 minutes adjustments. Couldn't a nation decide to have a continuously changing offset throughout the year? It might make their offset lookup table substantially longer, but this could 'solve' daylight…
Earlier quoted context omitted.
Unless you can propose a proper way to locally represent time where a person is currently present in relation to the position of the sun then no, time zones will never go away. I know time zones suck for us as programmers but it's a practical way to separate different regions that will experience different times of day differently. As long as we have clocks and times with "midnight"s and "noon"s, time zones will exis…
Just because you personally are used to a specific type of clock doesn’t mean you can’t imagine a different kind. Submarines use 24 hour clocks and give no hecks about where the sun is. The solution is to just use UTC. That’s it. That means in NYC you’d get to work at 13:00 and go home at 21:00, which used to be 9am-5pm. That’s it. Your whole transition has been completed. The rest is just what your calendar says. Ni…
I also think that your using the example of submarines -- notoriously an onerous lifestyle that very few are capable of living -- pretty much torpedoes your implicit suggestion that this would not be too much of a change.
I kind of thing a half hour daylight savings difference instead of an hour is a pretty low bar for the weirdest timezone. Almost any of the others are weirder: Antarctica/Troll definitely sounds weirder. The Moroccan and Gazan timezones that can't be expressed by the system as it was written because at least that means that they have some different kind of a rule, even if lunar time is well known. Same with the ones…
Especially when, even disregarding the ones with special rules, there's a couple that are 45 minutes off.
Excellent read around the acrobatics of timezone software. It really is quite flexible. It leads me to wonder. If it's all just an automated and finite offset, there's no reason for daylight savings policies to hew to 60 minutes adjustments. Couldn't a nation decide to have a continuously changing offset throughout the year? It might make their offset lookup table substantially longer, but this could 'solve' daylight…
The logical conclusion of going down that route would be to dispense with the concept of time zones altogether, and just revert to using local solar time.
Especially when everyone's half-hour blocks are misaligned with each other's so you can't even stack meetings efficiently.
The time zone in Palestine is a bit weird as well: https://en.wikipedia.org/wiki/Time_in_the_State_of_Palestine They have DST, but it's not on fixed dates, the government just announces each year when it's going to start and end. Sometimes with less that a week's notice, which must cause all kinds of interesting problems for people.
Instead, the authors prefer to use their own domain language — source files with a compiler to a binary format with a reference parser implementation. The thrust of this article is that’s mostly good enough but their domain language doesn’t include lunar information.
The downside would be size and runtime efficiency. I’m guessing tzdata is built the way it is so that it can be extremely small and efficient rather than large and, computationally speaking, comprehensive. You can run it on an Arm M0 as well as an Apple M2.
Earlier quoted context omitted.
Unless you can propose a proper way to locally represent time where a person is currently present in relation to the position of the sun then no, time zones will never go away. I know time zones suck for us as programmers but it's a practical way to separate different regions that will experience different times of day differently. As long as we have clocks and times with "midnight"s and "noon"s, time zones will exis…
Just because you personally are used to a specific type of clock doesn’t mean you can’t imagine a different kind. Submarines use 24 hour clocks and give no hecks about where the sun is. The solution is to just use UTC. That’s it. That means in NYC you’d get to work at 13:00 and go home at 21:00, which used to be 9am-5pm. That’s it. Your whole transition has been completed. The rest is just what your calendar says. Ni…
Okay. I work in Minneapolis and need to schedule a meeting with someone in London. How do I know what UTC time is during daylight hours for both participants? Well, we can use a formula that will tell us where the sun in the sky for a given longitude. But that's kind of a chore. So let's break ranges of longitude into zones and create a lookup table. Hang on a minute...
I've just traveled to Tokyo from Minneapolis. What time do I need to set my alarm to, to wake up an hour before most businesses open? Well, I can use trigonometry to figure out what UTC time the sun will rise at this location on Earth. But that's kind of a chore, so presumably each city will have an offset from UTC time that they all agree on to begin business hours. Hang on a minute...
Nah, the weirdest time zone is Africa/Addis_Ababa, which nobody in Ethiopia follows. Instead the locals offset the time by 6 hours. So the AM cycle starts at dawn (i.e. 6am), and the PM cycle starts at dusk (i.e. 6pm). https://en.wikipedia.org/wiki/Time_in_Ethiopia
Sounds like it could be a candidate. Any system which can't be expressed in standard software is stranger than every system that can be.
Let me define "local snoozing time" (LST): it's set to my local standard timezone as of today, but every time I hit the snooze button on my morning alarm it shifts 9 minutes backwards (the length of the snooze). By definition, I wake up at 8am in LST, regardless of what the world is doing.
If the time shifts by more than one hour compared to the prevailing timezone, LST shifts forwards by a whole number of hours on Saturday morning, 2am LST to minimize that difference.
This timezone is "boring" but uncomputable, since it depends on unpredictable events.
Earlier quoted context omitted.
You forgot that UTC (or timekeeping in general) itself is a diff.
Oh that's a great point! We have achieved diff^5 at last! Now that I think of it, we could even stretch it one more level. In practice UTC is "realized" as a "best of" diff to atomic clocks in labs around the world, which are themselves diff against a fixed time point, as you pointed out. So that realization technically changes when the official UTC bulletin[1] is published by BIPM. So diff^6! [1] https://www.bipm.or…
Earlier quoted context omitted.
Unless you can propose a proper way to locally represent time where a person is currently present in relation to the position of the sun then no, time zones will never go away. I know time zones suck for us as programmers but it's a practical way to separate different regions that will experience different times of day differently. As long as we have clocks and times with "midnight"s and "noon"s, time zones will exis…
Just because you personally are used to a specific type of clock doesn’t mean you can’t imagine a different kind. Submarines use 24 hour clocks and give no hecks about where the sun is. The solution is to just use UTC. That’s it. That means in NYC you’d get to work at 13:00 and go home at 21:00, which used to be 9am-5pm. That’s it. Your whole transition has been completed. The rest is just what your calendar says. Ni…