What I like about the tz database is that's it's technically a diff of a diff. It stores the difference across history, of the difference of each timezone with UTC. Right? So it's a diff^2. But! The tz database gets updates! So those commits are diffs of diffs of diffs, or diff^3.
Can we go further? You bet! It has a changelog, and that changelog is stored in git, so commits to the tz changelog are diff^4: they are changes to the list of changes to the list of changes to the list of changes to UTC.
The most interesting timezone I ever encountered is Europe/Moscow on and around January 1, 1900. If you decide to use that date as a zero date in your code (for example, to handle the transition from two digits per year), you will be in a lot of pain: the offset was +02:30:17. Yes, with 17 seconds! Demo: https://go.dev/play/p/lq36Plr1sIL
Yeah, for countries further away from the equator this would be crazy. Actually I thought Ethiopia is already far enough from the equator to have significant changes of sunrise/sunset times, but according to https://www.timeanddate.com/sun/ethiopia/addis-ababa, they only vary by ~ 40 minutes over the year, so I guess that's close enough to "constant" for most of the population...
But whether standard software is able to express this system is up to the software, not the system, no? Why is this way of timekeeping weird, apart from the arbitrary decision not to support it?
I would agree it's weird, but not because software doesn't support it, but because it's different from what the vast majority of the population of the world does. The fact that software doesn't support it is a downstream consequence of that.
The decision to not support it isn't "arbitrary" per se; it's a function of utility vs cost to implement (which a healthy dose of fudge). "Standard software" for timekeeping is far more useful precisely because it is used by far more people.
Maybe arbitrary was the wrong word. I understand that this is an implementation cost issue and I'm not saying that the decision not to pay this cost wasn't reasonable. My objection is not with tzdb, but with the characterisation of a real-life practice as weird just because software doesn't accommodate it. Shouldn't what people do be the reference for what is normal, rather than the rules encoded in software?
Ethiopian Christians have retained many Jewish customs compared to others, so you will also see them observing something like kosher diets. Although dusk is not sunset, it may be the case that they've adapted the cycle from Hebrew calendar observance.
Does anyone understand what was meant by "This is because almost every standard (except ISO8601, whatever) is just a file, and you can read it." Initially I thought it was because the PDF of ISO-8601 is not a file commonly distributed with operating system. But that's not unique to ISO8601, you won't find IEEE 1588-2019 or NMEA 0183 v4.11 on your computer either. For ~20$ I think I can buy a PDF of the standard from ISO. Is there something special about ISO8601 that is not contained in the standard?
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.
Without getting deep into politics I don't understand why they would prioritize spending effort on DST at all, seems like there are plenty of other concerns.
Again, without wanting to get too political, I think it's essentially bikeshedding. The Palestinian National Authority is riven with factional conflicts and has very limited state capacity. That almost inevitably leads to a lot of bickering over largely irrelevant decisions as a symbolic but hollow demonstration of political authority. The ability to make the decision takes on an importance completely out of proportion with the actual significance of the decision.
If your life is dominated by an us vs them dynamic small demonstrations of difference become hugely important.
In a similar vein different people in Xinjiang in China observe entirely different timezones - Han Chinese observe Beijing time (because China is insane and uses one timezone despite spanning 5), while Uyghurs observe a local time 2 hours behind.
It’s a small show of resistance, which is sometimes all a people have if they have limited control of their own affairs.
The "Asia/Jerusalem" weirdness is because Daylight Savings Time is a big church-and-state issue. Religious people want the workday to be convenient for holidays that start at sunset.
This led to decades (up to the mid-'00s) where Daylight Savings was the result of annual negotiations between religious and secular parties. It often caused problems when the decision wasn't made until juuuust before the transition date.
There are still exceptions built in to prevent Daylight Savings from ending on Rosh HaShanah, so that's probably the future stuff.
Reading this, and considering the limited advantages of DST (especially for a country that is relatively far to the south), I wonder why they didn't decide to scrap DST completely? Maybe they will if the EU eventually manages to do it?
Earlier this year I had to write a function to find the current local time given a US address. The naive way to do so would be via a static mapping of state to time zone but there are a few edge cases that preclude doing this; in the interest of cost and speed relative to this specific application I spent a few dollars on a CSV that maps every US ZIP code to UTC offset and whether DST is followed (among other data). pytz takes IANA timezone names so I ended up having to map offset and DST info manually to specific timezones. As it turns out the US has a fair number of weird edge cases for overseas territories and military bases that necessitated the use of things like "Etc" zones [1] that have funky semantics (because of Unix for some reason if Wikipedia is to be believed).
> The naive way to do so would be via a static mapping of state to time zone but there are a few edge cases that preclude doing this
More than a few, state is really the wrong resolution here, US timezones follow counties and native reservations borders.
ZIP codes should probably be good enough but I'd be careful too. If your volume of addresses isn't too crazy, the robust way is to reverse geocode them and use a library that gets you the IANA identifier from timezone shapes.
A good approach would be to map a zip code to the named timezone (e.g. US/Eastern). Then, if you need to produce the UTC offset, apply the timezone to a date using pytz and get the offset.
The named timezone is special as it is constant. The UTC offset timezone (e.g. "-05:00") and the shorthand name (e.g. "EST") is NOT constant over time for a given location, because of daylight savings time. "US/Eastern" flips between "-05:00" and "-05:00", as well as between "EDT" and "EST".
If you ask someone what their timezone is and offer them offsets or the short names, it causes confusion for everyone.
To me, one of the key framing ideas that almost all dates/times are actually a set of matching-rules that you are monitoring for. You can guess how many seconds will elapse until the match triggers, but you can't be totally sure [0] until it happens, and in some cases it will never quite happen at all. [1]
Then the second half is often to reverse your "I think it will happen X seconds from now" delta-guess into "I'm also guessing that your timezone's clocks will say Y when it happens."
Just don't forget to keep track of which timezones is controlling the event versus which timezones it is being displayed in.
____
[1] Your UTC estimate might occur plus or minus leap seconds. TAI is safer, unless somebody discovers something exciting and new that changes the behavior of cesium atoms.
[0] Such as if the time zone vanishes because the country is gone. Or perhaps the 1:30 to 2:00 thing couldn't exactly happen because the clocks went forward from 1:00 to 2:00 with a missing hour.
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 that are in Apple's naughty list because they're transitions the day before some day - again, not very weird, but at least it's weird enough to break things.
But I do agree with leap seconds: it's absolute trivia, not a useful thing for a programmer to know. Your computer smears them and you don't even know when they happened. You could completely forget them. Except that countries transitioned from ignoring leap seconds to considering them, so the switch in Australia from "GMT+x" to "UTC+x" a couple of decades ago was the transition from ignoring leap seconds to incorporating them. The fact that this is almost universally ignored is probably for the better.
Leap seconds are generally trivia, but they become absolutely crucial in applications where multiple parties must be in exact agreement about chronology - the obvious example being financial transactions. A lot of markets were closed for the leap second and many banks still suspend all transactions during any change of local time to mitigate the risk of error.
Even in applications where we don't particularly care, there have been a surprisingly large number of leap second-related bugs. CGPM have decided to abolish the leap second for good reason.
> But I do agree with leap seconds: it's absolute trivia, not a useful thing for a programmer to know.
By and large, I agree with this.
But I've always found it a bit funny when a large organisation [1] says "our servers have sub-millisecond timing accuracy, thanks to GPS synchronization and these PCIe rubidium atomic clock cards we've developed" while at the same time saying [2] "we smear leapseconds over the course of a day, in practice it doesn't matter if a server's time is off by ±0.5 seconds"
The thing that super accurate timestamps buys you is common agreement across your infrastructure as to what the time is. This basically makes distributed systems work faster/better/whatever.
The relation between that time and what the rest of the world thinks the time is is actually less relevant.
Antarctica/Troll is not that weird. Really they use just two times: Cape Town time during short summer and Norway time otherwise. Unfortunately, Norway time happens to have DST ;-)
The date of Ramadan is not well known because it's based on being able to see the moon from the local position on Earth. If the sky is particularly overcast for instance, then you cannot see the moon, regardless of where the moon is.
This presents problems for implementation of the calendar into the workings of a nation state. Many countries that adopt the Islamic calendar officially use an approximation, a pre-calculated date based on the moon's predicted visibility at a particular position.
The Islamic calendar is therefore not really one calendar, but two: the observational Islamic calendar and the predicted calendar, and both have a dependence on a location from which either real observations are made, or predicted observations are made.
> But I do agree with leap seconds: it's absolute trivia, not a useful thing for a programmer to know.
Maybe, all I know is that it was relevant for me during the first years in industry. If you work with timeseries which comes from source systems you don't 100% controll, like in many industrial settings, its important to know about them, and how they are handled upstream. Do the source do smearing, or does it just sync every X hours? Does it sync with NTP, which will smear (slew) the change, or have they implemented their own thing? Do they just run `ntpd -q` regularly?
But yeah, as I type it out I realize that most programmers probably don't work in that domain:-p
I find it slightly ironic that a blog that’s educating (and entertaining) us on time and timezones does not itself mention when its blogposts were published, at least on mobile.
This one appears to have been published in the summer of 2024.
While there's no explicit publication date, there are a few shell commands which strongly imply that the blogger was writing on or about "Tue Jul 30 23:52:11 UTC 2024".
"Running cron jobs on an hourly basis doesn’t in practice have very weird interactions with DST"
Of course every sane person runs their default system clock on UTC and lets users pick their own local time. That way cron always does the "right thing"(TM).
In my opinion, the best way to see it is not to pretend their are weird timezones.
It is not because most of the world do summer time and that when they do they have a 1h transitions that we should take it for granted.
This article do not mention the Chatham Standard Time Zone from Chatham Islands archipelago in NZ which is 45 minutes ahead of New Zealand Daylight Time, nor the Central Western Standard Time (Australia/Eucla). Also wikipedia mention there is a "train timezone" for the Indian Pacific train. I wonder if other trains have a dedicated timezone?
Yes for some reason I read the following sentence backwards thinking that 410 timezones were observing DST while 185 did not.
> Hmm. 410 timezones just don’t DST at all. 185 have a 3600-second, i.e. 1-hour, difference.
My point stands that there is no normality, just governments taking different decisions and being entitled to it and what the majority does is not relevant.
Agreed, and the humor is restrained. Often there are posts (which tend to also have an annoying amount of gifs) which just overdo it. But here it’s neatly used to lighten the writing.
I always say that timezones and font rendering are the most sucking problems that developer can encounter. Both have a ton of weird quirks, both implemented differently across various target devices/OSes and require a lot of time and effort to implement reasonably right.
UTC is generally a good idea for storing, but there are still some ways to have that bite you. If a user enters a local date time for a future event in a particular time zone, converting that to UTC could result in incorrect behavior if the timezone definition changes. It depends on if the user meant that UTC time or if they meant the local time.
Oddly was just reading something yesterday and it mentioned that in the UK there were years during the war where we had double DST for energy saving reasons. (although we went between 1 hour and 2 hours, so it was only really a change compared to the norm)
I thing, more helpfully, that would better sync up UK time with time on much of the continent. Quite useful if you're doing a lot of things internationally.
Yesterday in the UK, sunrise was about 7am and sunset was about 4:40pm. Electricity demand peaked at about 5:30pm, in the overlap between workplaces closing for the evening and people returning home and turning everything on. There's a straightforward case for either staying on BST (UTC+1) throughout the year, or (as was the case during WWII) using UTC+2 during summer and UTC+1 during winter, effectively bringing the UK in line with CET/CEST.
The key factor in the war was the blackout - street lighting was turned off for the duration and vehicle headlights were mostly covered over, to avoid providing easy targets for night bombing raids. This obviously hugely increased the hazards posed by the early sunsets under GMT.
The idea behind DST is that it shifts working hours into daylight hours during the darker months. This would theoretically cut down on energy use for lighting during those hours.
Of course offices, factories and even schools still use artificial lighting even during daylight hours. And now the energy use of artificial lighting is much lower than back when everything used filament.
Even ignoring the energy saving part, it sucks waking up and leaving for work or school while it is still dark.
A while ago Turkey switched to a different timezone and stopped doing DST for reasons and now everyone was waking up one hour early in winters. Considering how bad traffic is in larger cities that meant a lot of people will be waking up and going to work or school while it is still dark.
It doesn't! That is why some countries want to leave one time for the whole year.
When lots of power were used by lighting, it must have saved something...
I still hope that someday the whole world will run on UTC0 and there is no more time zones madness. I know the day will likely never come but I like to keep dreaming.
Some dates will change when at relatively strange times. For some, the date change will be two hours into the workday. That seems odd. And you lose some info too: if I want a 07:30 (am) meeting, is that during the working hours of my target location? With offsets, I can see that it is 12:30pm at my target location and know that I am scheduling over lunch very likely. With no timezones, how do I know what time of day it is there? Recall some anchor time and do mental math each time? "Morning in London is 13:00, so four hours later right before lunch is 17:00, and for an LA meeting, let's see, morning there is 05:00, so 17:00 is evening time, I think
> the date change will be two hours into the workday. That seems odd
Seconds minutes and hours can change but the day cannot?
> mental math each time
Usually meetings are setup using an app and shared calendars should actually help here, a person can have meeting slots and out of office time, that should provide the same info. logistically I don't see that much of a difference from the current situation
I'd rather timezones be split based on actual logic rather than politics and eliminate things like daylight savings. It's insane to me that China has one timezone because they felt like it. People must sleep terribly in certain regions.
> These time zones have hundreds of hard-coded transitions out into the future. I don’t understand why, it’s not like they all have lunar calendar stuff going on.
Without any additional update to the tz database, all annual transitions are assumed to continue indefinitely. So TZif version 1 would repeat transitions up to January 2038 (i.e. the end of signed 32-bit time_t), while version 2 or later would keep them for the compatibility (see the section 4 of RFC 8536) but also include the algorithmic description in the footer for later dates.
So this is a thing: I caught the Snake emoji behaving differently in some code because it was coded one thing before #celebrity-thing, and the opposite months later.
Snake Emoji Kanye vibes are the weirdest timezone.
This might not 'mean much' to the computer, but it means a lot to the human. The computer uses it to communicate with the human and the humans between each other. When I arrange a meeting across timezones I will say CET 16.00 or ET3.00PM and they will understand it faster than saying how much offset we are from UCT.
> America/Nuuk does daylight savings at -01:00 (yes, with a negative)
Somewhat related: Europe/Dublin has a negative DST offset. Irish DST runs through the European winter (i.e. the opposite of the other European timezones).
I think you misread that. America/Nuuk doesn't have reverse DST (which is easily solved by just switching DST and non-DST around). It starts DST at a negative offset because the offset is defined as relative to the previous day.
> Btw it’s called UTC (Universal Time Coordinated? huh?) because the same folks who publish UTC also publish UT1, which is UTC sans the leap seconds.
I’m not sure that’s right! According to legend among metrologists I’ve talked to, “UTC” was chosen as a compromise candidate: it makes sense as an acronym in neither English nor French.
Along with Kathmandu for weird offsets is Australian Central Western Standard Time (UTC +8:45), used in a tiny area of Australia with the largest town being Eucla (population 37). Being mainly within Western Australia (which doesn't use daylight savings) but partially within South Australia (which does use daylight savings) there has also been informal use of UTC+9:45
Historically there was also Dublin mean time (UTC -00:25.21) and Warsaw mean time (UTC+1:24)
I wonder why the dst transition hours are encoded in local time. Wouldn't it be easier to do it in UTC? There is no need to differentiate between the same hour before and after change then.
Suppose in local time (which is, say, UTC+3) the DST transition is on something like "last Sunday of 10th month at 02:00", which might then in UTC become "last Saturday of 10th month at 23:00, except if that Saturday is the last day of the month, then the second to last Saturday". In effect, if conversion to UTC causes the transition to move to a different day, it might also be on a different week or month, causing headache.
(Or did you ask something else entirely? It wouldn't be the first time I misunderstood things about time zones.)
Perhaps to decouple DST transition rules from other time-zone changes. So if the time-zone offset is adjusted for some other reason then the DST rule does not also need to be changed.
Hard-coded yearly transitions for a particular region, because they just have to have their own, special rules? Transitioning to DST on Sunday at -01:00 (minus one o'clock)? Or at 24:00?
Honestly, the IT world has a certain amount of influence. There comes a time where we could collectively just say "no". No, you are not that special, use any of the already incredibly flexible options that you have.
I love time/date problems. One of the best references on the subject of calendars is "Standard C Date/Time Library: Programming the World's Calendars and Clocks" by Lance Latham. He really goes into a lot of detail on various calendaring systems, some really cooky, https://amzn.to/4hjv5L3
BTW. A long, informative post without a single mention of AI. A rare thing these days.
Oh wow, what a coincidence, I was just looking at Lord Howe Island on a map of species conservation.
For anyone who doesn't know: Lord Howe Island is the last true paradise on Earth.
I went there on holidays a few years back based on two travel review recommendations. Both were by professional travellers that had been to pretty much everywhere, and both said it's the best place they've ever been. The reasoning was that every other tropical island has "something" wrong with it. Pushy locals trying to sell you stuff, sharks in the water, malaria, pollution, crime, poverty, or something.
Lord Howe is about as safe as it's possible to get, civilised beyond belief, pristine, unpolluted, etc...
It's one of the last places in the world with undamaged, unbleached coral reefs in protected waters. The diving there is just unbelievable, more beautiful than any Planet Earth documentary you've seen.
Birds nest on the beach, and you have to step over them gently because there's thousands of them and the juveniles can't fly yet.
I met the police officer of the island and pointedly asked him when was the last time he had to deal with crime.
"Crime... crime... let's see." he said, counting on his fingers slowly "Umm... seven years ago there was a domestic violence report because a tourist slapped his wife in an argument."
The hotel doors have no locks. There's $500 in cash in a tin next to a shack full of equipment on the beach with a "honesty system" rental price list sign next to it. The bloke selling you coke cans at the milk bar bought it with the $20 million he made in the stock market. Half the tourists go there by private plane. Ballmer's son took his super yacht there with a harem of models. And on, and on.
What I like about the tz database is that's it's technically a diff of a diff. It stores the difference across history, of the difference of each timezone with UTC. Right? So it's a diff^2. But! The tz database gets updates! So those commits are diffs of diffs of diffs, or diff^3.
Can we go further? You bet! It has a changelog, and that changelog is stored in git, so commits to the tz changelog are diff^4: they are changes to the list of changes to the list of changes to the list of changes to UTC.
You forgot that UTC (or timekeeping in general) itself is a diff.
The most interesting timezone I ever encountered is Europe/Moscow on and around January 1, 1900. If you decide to use that date as a zero date in your code (for example, to handle the transition from two digits per year), you will be in a lot of pain: the offset was +02:30:17. Yes, with 17 seconds! Demo: https://go.dev/play/p/lq36Plr1sIL
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
Ethiopian time keeping is peculiar all over.
https://en.wikipedia.org/wiki/Ethiopian_calendar
The Ethiopian calendar has twelve months, all thirty days long, and five or six epagomenal days, which form a thirteenth month.
That's very similar to how the romans conceived of time. Wonder if it's an old relic from when north africa was a bunch of provinces.
https://en.wikipedia.org/wiki/Roman_timekeeping
"An hour was defined as one twelfth of the daytime"
That must have been fun for the Romans here in Scotland - an hour would be roughly two and a half time as long in winter as in summer!
For country near equator that is not actually unreasonable system to define day cycle.
Yeah, for countries further away from the equator this would be crazy. Actually I thought Ethiopia is already far enough from the equator to have significant changes of sunrise/sunset times, but according to https://www.timeanddate.com/sun/ethiopia/addis-ababa, they only vary by ~ 40 minutes over the year, so I guess that's close enough to "constant" for most of the population...
And they live 7 years in the past.
They do. So I guess the observed timezone is UTC-61314.
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.
But whether standard software is able to express this system is up to the software, not the system, no? Why is this way of timekeeping weird, apart from the arbitrary decision not to support it?
I would agree it's weird, but not because software doesn't support it, but because it's different from what the vast majority of the population of the world does. The fact that software doesn't support it is a downstream consequence of that.
The decision to not support it isn't "arbitrary" per se; it's a function of utility vs cost to implement (which a healthy dose of fudge). "Standard software" for timekeeping is far more useful precisely because it is used by far more people.
Maybe arbitrary was the wrong word. I understand that this is an implementation cost issue and I'm not saying that the decision not to pay this cost wasn't reasonable. My objection is not with tzdb, but with the characterisation of a real-life practice as weird just because software doesn't accommodate it. Shouldn't what people do be the reference for what is normal, rather than the rules encoded in software?
Software doesn’t accomodate it because it’s weird relative to literally the rest of the world.
Ethiopian Christians have retained many Jewish customs compared to others, so you will also see them observing something like kosher diets. Although dusk is not sunset, it may be the case that they've adapted the cycle from Hebrew calendar observance.
Does anyone understand what was meant by "This is because almost every standard (except ISO8601, whatever) is just a file, and you can read it." Initially I thought it was because the PDF of ISO-8601 is not a file commonly distributed with operating system. But that's not unique to ISO8601, you won't find IEEE 1588-2019 or NMEA 0183 v4.11 on your computer either. For ~20$ I think I can buy a PDF of the standard from ISO. Is there something special about ISO8601 that is not contained in the standard?
Possibly joking about the .iso file-type for optical disc images?
Or maybe that 'most' ISO standards that are encountered by engineers are defining file-types.
I'm also a big fan of ISO-3166 though !
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.
Without getting deep into politics I don't understand why they would prioritize spending effort on DST at all, seems like there are plenty of other concerns.
Again, without wanting to get too political, I think it's essentially bikeshedding. The Palestinian National Authority is riven with factional conflicts and has very limited state capacity. That almost inevitably leads to a lot of bickering over largely irrelevant decisions as a symbolic but hollow demonstration of political authority. The ability to make the decision takes on an importance completely out of proportion with the actual significance of the decision.
I don't see why announcing DST would be a big effort. And it saves on electricity costs.
If your life is dominated by an us vs them dynamic small demonstrations of difference become hugely important.
In a similar vein different people in Xinjiang in China observe entirely different timezones - Han Chinese observe Beijing time (because China is insane and uses one timezone despite spanning 5), while Uyghurs observe a local time 2 hours behind.
It’s a small show of resistance, which is sometimes all a people have if they have limited control of their own affairs.
Not sure if true today, but used to be the case in Brazil too. Once almost missed a flight because of that.
The "Asia/Jerusalem" weirdness is because Daylight Savings Time is a big church-and-state issue. Religious people want the workday to be convenient for holidays that start at sunset.
This led to decades (up to the mid-'00s) where Daylight Savings was the result of annual negotiations between religious and secular parties. It often caused problems when the decision wasn't made until juuuust before the transition date.
There are still exceptions built in to prevent Daylight Savings from ending on Rosh HaShanah, so that's probably the future stuff.
Reading this, and considering the limited advantages of DST (especially for a country that is relatively far to the south), I wonder why they didn't decide to scrap DST completely? Maybe they will if the EU eventually manages to do it?
If they didn’t have that to argue about, what else would they do with their spare time?
Earlier this year I had to write a function to find the current local time given a US address. The naive way to do so would be via a static mapping of state to time zone but there are a few edge cases that preclude doing this; in the interest of cost and speed relative to this specific application I spent a few dollars on a CSV that maps every US ZIP code to UTC offset and whether DST is followed (among other data). pytz takes IANA timezone names so I ended up having to map offset and DST info manually to specific timezones. As it turns out the US has a fair number of weird edge cases for overseas territories and military bases that necessitated the use of things like "Etc" zones [1] that have funky semantics (because of Unix for some reason if Wikipedia is to be believed).
[1] https://en.wikipedia.org/wiki/Tz_database#Area
> The naive way to do so would be via a static mapping of state to time zone but there are a few edge cases that preclude doing this
More than a few, state is really the wrong resolution here, US timezones follow counties and native reservations borders.
ZIP codes should probably be good enough but I'd be careful too. If your volume of addresses isn't too crazy, the robust way is to reverse geocode them and use a library that gets you the IANA identifier from timezone shapes.
https://github.com/RomanIakovlev/timeshape is maintained by a former coworker who could open source some of the work we did internally.
A good approach would be to map a zip code to the named timezone (e.g. US/Eastern). Then, if you need to produce the UTC offset, apply the timezone to a date using pytz and get the offset.
The named timezone is special as it is constant. The UTC offset timezone (e.g. "-05:00") and the shorthand name (e.g. "EST") is NOT constant over time for a given location, because of daylight savings time. "US/Eastern" flips between "-05:00" and "-05:00", as well as between "EDT" and "EST".
If you ask someone what their timezone is and offer them offsets or the short names, it causes confusion for everyone.
To me, one of the key framing ideas that almost all dates/times are actually a set of matching-rules that you are monitoring for. You can guess how many seconds will elapse until the match triggers, but you can't be totally sure [0] until it happens, and in some cases it will never quite happen at all. [1]
Then the second half is often to reverse your "I think it will happen X seconds from now" delta-guess into "I'm also guessing that your timezone's clocks will say Y when it happens."
Just don't forget to keep track of which timezones is controlling the event versus which timezones it is being displayed in. ____
[1] Your UTC estimate might occur plus or minus leap seconds. TAI is safer, unless somebody discovers something exciting and new that changes the behavior of cesium atoms.
[0] Such as if the time zone vanishes because the country is gone. Or perhaps the 1:30 to 2:00 thing couldn't exactly happen because the clocks went forward from 1:00 to 2:00 with a missing hour.
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 that are in Apple's naughty list because they're transitions the day before some day - again, not very weird, but at least it's weird enough to break things.
But I do agree with leap seconds: it's absolute trivia, not a useful thing for a programmer to know. Your computer smears them and you don't even know when they happened. You could completely forget them. Except that countries transitioned from ignoring leap seconds to considering them, so the switch in Australia from "GMT+x" to "UTC+x" a couple of decades ago was the transition from ignoring leap seconds to incorporating them. The fact that this is almost universally ignored is probably for the better.
Leap seconds are generally trivia, but they become absolutely crucial in applications where multiple parties must be in exact agreement about chronology - the obvious example being financial transactions. A lot of markets were closed for the leap second and many banks still suspend all transactions during any change of local time to mitigate the risk of error.
Even in applications where we don't particularly care, there have been a surprisingly large number of leap second-related bugs. CGPM have decided to abolish the leap second for good reason.
https://en.wikipedia.org/wiki/Leap_second#Other_reported_sof...
> But I do agree with leap seconds: it's absolute trivia, not a useful thing for a programmer to know.
By and large, I agree with this.
But I've always found it a bit funny when a large organisation [1] says "our servers have sub-millisecond timing accuracy, thanks to GPS synchronization and these PCIe rubidium atomic clock cards we've developed" while at the same time saying [2] "we smear leapseconds over the course of a day, in practice it doesn't matter if a server's time is off by ±0.5 seconds"
[1] https://engineering.fb.com/2021/08/11/open-source/time-appli... [2] https://engineering.fb.com/2020/03/18/production-engineering...
The thing that super accurate timestamps buys you is common agreement across your infrastructure as to what the time is. This basically makes distributed systems work faster/better/whatever.
The relation between that time and what the rest of the world thinks the time is is actually less relevant.
Antarctica/Troll is not that weird. Really they use just two times: Cape Town time during short summer and Norway time otherwise. Unfortunately, Norway time happens to have DST ;-)
> even if lunar time is well known
The date of Ramadan is not well known because it's based on being able to see the moon from the local position on Earth. If the sky is particularly overcast for instance, then you cannot see the moon, regardless of where the moon is.
This presents problems for implementation of the calendar into the workings of a nation state. Many countries that adopt the Islamic calendar officially use an approximation, a pre-calculated date based on the moon's predicted visibility at a particular position.
The Islamic calendar is therefore not really one calendar, but two: the observational Islamic calendar and the predicted calendar, and both have a dependence on a location from which either real observations are made, or predicted observations are made.
I don't know how Morocco or Gaza do it.
> But I do agree with leap seconds: it's absolute trivia, not a useful thing for a programmer to know.
Maybe, all I know is that it was relevant for me during the first years in industry. If you work with timeseries which comes from source systems you don't 100% controll, like in many industrial settings, its important to know about them, and how they are handled upstream. Do the source do smearing, or does it just sync every X hours? Does it sync with NTP, which will smear (slew) the change, or have they implemented their own thing? Do they just run `ntpd -q` regularly?
But yeah, as I type it out I realize that most programmers probably don't work in that domain:-p
I find it slightly ironic that a blog that’s educating (and entertaining) us on time and timezones does not itself mention when its blogposts were published, at least on mobile.
This one appears to have been published in the summer of 2024.
Seems like pretty timeless content to me.
While there's no explicit publication date, there are a few shell commands which strongly imply that the blogger was writing on or about "Tue Jul 30 23:52:11 UTC 2024".
"Running cron jobs on an hourly basis doesn’t in practice have very weird interactions with DST"
Of course every sane person runs their default system clock on UTC and lets users pick their own local time. That way cron always does the "right thing"(TM).
That's true if you need to clean up temporary files every night or make a backup.
But what if your cronjob has an effect in the physical world, locally? E.g. open the parking gates every morning.
The world is inherently messy :-)
I think the old Riyadh timezone is the weirdest personally https://github.com/eggert/tz/blob/be62d5918223b4df209cc94163...
In my opinion, the best way to see it is not to pretend their are weird timezones.
It is not because most of the world do summer time and that when they do they have a 1h transitions that we should take it for granted.
This article do not mention the Chatham Standard Time Zone from Chatham Islands archipelago in NZ which is 45 minutes ahead of New Zealand Daylight Time, nor the Central Western Standard Time (Australia/Eucla). Also wikipedia mention there is a "train timezone" for the Indian Pacific train. I wonder if other trains have a dedicated timezone?
> I wonder if other trains have a dedicated timezone?
They used to, railway time is how our timezone system came to be.
> It is not because most of the world do summer time
Eh? Most of the world don't do summer time.
Yes for some reason I read the following sentence backwards thinking that 410 timezones were observing DST while 185 did not.
> Hmm. 410 timezones just don’t DST at all. 185 have a 3600-second, i.e. 1-hour, difference.
My point stands that there is no normality, just governments taking different decisions and being entitled to it and what the majority does is not relevant.
I really love this way of writing. Informational with occasional bits of humor. It makes it read and ingest.
Agreed, and the humor is restrained. Often there are posts (which tend to also have an annoying amount of gifs) which just overdo it. But here it’s neatly used to lighten the writing.
I'm going to steal "Greenland is part of the greater EU cinematic universe".
Reminds me of when Tom Scott descended into madness at trying to account for time zones:
https://www.youtube.com/watch?v=-5wpm-gesOY
Somehow I end up watching this about twice a year
I always say that timezones and font rendering are the most sucking problems that developer can encounter. Both have a ton of weird quirks, both implemented differently across various target devices/OSes and require a lot of time and effort to implement reasonably right.
> Wrote a script in emacs lisp to calculate Ramadan
I found this pretty funny, but a spot on solution. The solar/calendar features of Emacs are surprisingly robust and easy to work with.
I’ve found the best way to deal with TZ conversions, is to use UTC as a common fulcrum.
I convert the target TZ to UTC, using my local utility, then use my local TZ utility to convert from UTC to local.
But I write iOS software, so I have very solid local tools at hand. It might be more problematic, on, say, a webserver.
On a related note, I wrote this utility[0], some time ago. It uses the TZ map from the TZ Boundary Builder project[1].
[0] https://github.com/LittleGreenViper/LGV_TZ_Lookup
[1] https://github.com/evansiroky/timezone-boundary-builder
UTC is generally a good idea for storing, but there are still some ways to have that bite you. If a user enters a local date time for a future event in a particular time zone, converting that to UTC could result in incorrect behavior if the timezone definition changes. It depends on if the user meant that UTC time or if they meant the local time.
> if the timezone definition changes
Or if DST kicks in/out. No need to have the definitions change.
That's why I do it at the time the query is made. I don't ever store UTC.
Oddly was just reading something yesterday and it mentioned that in the UK there were years during the war where we had double DST for energy saving reasons. (although we went between 1 hour and 2 hours, so it was only really a change compared to the norm)
https://www.atlasobscura.com/articles/the-extreme-daylight-s...
I thing, more helpfully, that would better sync up UK time with time on much of the continent. Quite useful if you're doing a lot of things internationally.
I don't really understand how that would save energy. Did people work 7am-3pm days or something?
Yesterday in the UK, sunrise was about 7am and sunset was about 4:40pm. Electricity demand peaked at about 5:30pm, in the overlap between workplaces closing for the evening and people returning home and turning everything on. There's a straightforward case for either staying on BST (UTC+1) throughout the year, or (as was the case during WWII) using UTC+2 during summer and UTC+1 during winter, effectively bringing the UK in line with CET/CEST.
The key factor in the war was the blackout - street lighting was turned off for the duration and vehicle headlights were mostly covered over, to avoid providing easy targets for night bombing raids. This obviously hugely increased the hazards posed by the early sunsets under GMT.
https://www.timeanddate.com/astronomy/uk
https://www.energydashboard.co.uk/live
https://www.bbc.co.uk/news/articles/c0mznrv3jvmo
The idea behind DST is that it shifts working hours into daylight hours during the darker months. This would theoretically cut down on energy use for lighting during those hours.
Of course offices, factories and even schools still use artificial lighting even during daylight hours. And now the energy use of artificial lighting is much lower than back when everything used filament.
Even ignoring the energy saving part, it sucks waking up and leaving for work or school while it is still dark.
A while ago Turkey switched to a different timezone and stopped doing DST for reasons and now everyone was waking up one hour early in winters. Considering how bad traffic is in larger cities that meant a lot of people will be waking up and going to work or school while it is still dark.
It doesn't! That is why some countries want to leave one time for the whole year. When lots of power were used by lighting, it must have saved something...
The Japanese calendar has always been the most fascinating date/time thing for me:
https://devblogs.microsoft.com/dotnet/handling-a-new-era-in-...
I still hope that someday the whole world will run on UTC0 and there is no more time zones madness. I know the day will likely never come but I like to keep dreaming.
Some dates will change when at relatively strange times. For some, the date change will be two hours into the workday. That seems odd. And you lose some info too: if I want a 07:30 (am) meeting, is that during the working hours of my target location? With offsets, I can see that it is 12:30pm at my target location and know that I am scheduling over lunch very likely. With no timezones, how do I know what time of day it is there? Recall some anchor time and do mental math each time? "Morning in London is 13:00, so four hours later right before lunch is 17:00, and for an LA meeting, let's see, morning there is 05:00, so 17:00 is evening time, I think
> the date change will be two hours into the workday. That seems odd
Seconds minutes and hours can change but the day cannot?
> mental math each time
Usually meetings are setup using an app and shared calendars should actually help here, a person can have meeting slots and out of office time, that should provide the same info. logistically I don't see that much of a difference from the current situation
I'd rather timezones be split based on actual logic rather than politics and eliminate things like daylight savings. It's insane to me that China has one timezone because they felt like it. People must sleep terribly in certain regions.
> These time zones have hundreds of hard-coded transitions out into the future. I don’t understand why, it’s not like they all have lunar calendar stuff going on.
Without any additional update to the tz database, all annual transitions are assumed to continue indefinitely. So TZif version 1 would repeat transitions up to January 2038 (i.e. the end of signed 32-bit time_t), while version 2 or later would keep them for the compatibility (see the section 4 of RFC 8536) but also include the algorithmic description in the footer for later dates.
So this is a thing: I caught the Snake emoji behaving differently in some code because it was coded one thing before #celebrity-thing, and the opposite months later.
Snake Emoji Kanye vibes are the weirdest timezone.
Wait, how is it different before/after?
A friend of mine has been visiting places with weird time related things going on, because it is interesting and takes you funny places.
He has been to Lord Howe. Now I know why. He has a user account on HN. I will ask him if he wants to make an appearance here...
> With a “designator” time that doesn’t mean much
This might not 'mean much' to the computer, but it means a lot to the human. The computer uses it to communicate with the human and the humans between each other. When I arrange a meeting across timezones I will say CET 16.00 or ET3.00PM and they will understand it faster than saying how much offset we are from UCT.
> America/Nuuk does daylight savings at -01:00 (yes, with a negative)
Somewhat related: Europe/Dublin has a negative DST offset. Irish DST runs through the European winter (i.e. the opposite of the other European timezones).
(More details here: https://github.com/golang/go/issues/56743#issuecomment-13157... )
Edit: To be clear: the quote is referring to a negative DST start, rather than a negative DST offset.
In the github repo the article links, there is a large number of comments about the Europe/Dublin time zone in the europe file, including one quote from Ulysses: https://github.com/eggert/tz/blob/7748036bace8562b9c047f368c...
I think you misread that. America/Nuuk doesn't have reverse DST (which is easily solved by just switching DST and non-DST around). It starts DST at a negative offset because the offset is defined as relative to the previous day.
Yes, this is indeed a different situation and my comment doesn't make that clear. Thank for pointing that out. I've made an edit.
> Btw it’s called UTC (Universal Time Coordinated? huh?) because the same folks who publish UTC also publish UT1, which is UTC sans the leap seconds.
I’m not sure that’s right! According to legend among metrologists I’ve talked to, “UTC” was chosen as a compromise candidate: it makes sense as an acronym in neither English nor French.
Along with Kathmandu for weird offsets is Australian Central Western Standard Time (UTC +8:45), used in a tiny area of Australia with the largest town being Eucla (population 37). Being mainly within Western Australia (which doesn't use daylight savings) but partially within South Australia (which does use daylight savings) there has also been informal use of UTC+9:45
Historically there was also Dublin mean time (UTC -00:25.21) and Warsaw mean time (UTC+1:24)
I wonder why the dst transition hours are encoded in local time. Wouldn't it be easier to do it in UTC? There is no need to differentiate between the same hour before and after change then.
Suppose in local time (which is, say, UTC+3) the DST transition is on something like "last Sunday of 10th month at 02:00", which might then in UTC become "last Saturday of 10th month at 23:00, except if that Saturday is the last day of the month, then the second to last Saturday". In effect, if conversion to UTC causes the transition to move to a different day, it might also be on a different week or month, causing headache.
(Or did you ask something else entirely? It wouldn't be the first time I misunderstood things about time zones.)
Perhaps to decouple DST transition rules from other time-zone changes. So if the time-zone offset is adjusted for some other reason then the DST rule does not also need to be changed.
This is awesome - I have always kind of wondered how this stuff was implemented, but never looked it up.
I implemented `DateTime` in Dart and Toit and wrote a blog post about the things I noticed: https://medium.com/@florian_32814/date-time-526a4f86badb
Timezones are fun...
Hard-coded yearly transitions for a particular region, because they just have to have their own, special rules? Transitioning to DST on Sunday at -01:00 (minus one o'clock)? Or at 24:00?
Honestly, the IT world has a certain amount of influence. There comes a time where we could collectively just say "no". No, you are not that special, use any of the already incredibly flexible options that you have.
> There comes a time where we could collectively just say "no"
Well, C23 mandates a byte is 8 bits, and POSIX 2024 disallows newlines in filename, so we do exercise that right times to times.
I think you've got who's serving whom the wrong way round.
https://en.wikipedia.org/wiki/Sandringham_time was a crazy one
The tz-iana mailing list is a lot of fun to subscribe to.
I love time/date problems. One of the best references on the subject of calendars is "Standard C Date/Time Library: Programming the World's Calendars and Clocks" by Lance Latham. He really goes into a lot of detail on various calendaring systems, some really cooky, https://amzn.to/4hjv5L3
BTW. A long, informative post without a single mention of AI. A rare thing these days.
Clean link without affiliate code: https://www.amazon.co.uk/Standard-Date-Time-Library-Programm...
Nice morning reading
Oh wow, what a coincidence, I was just looking at Lord Howe Island on a map of species conservation.
For anyone who doesn't know: Lord Howe Island is the last true paradise on Earth.
I went there on holidays a few years back based on two travel review recommendations. Both were by professional travellers that had been to pretty much everywhere, and both said it's the best place they've ever been. The reasoning was that every other tropical island has "something" wrong with it. Pushy locals trying to sell you stuff, sharks in the water, malaria, pollution, crime, poverty, or something.
Lord Howe is about as safe as it's possible to get, civilised beyond belief, pristine, unpolluted, etc...
It's one of the last places in the world with undamaged, unbleached coral reefs in protected waters. The diving there is just unbelievable, more beautiful than any Planet Earth documentary you've seen.
Birds nest on the beach, and you have to step over them gently because there's thousands of them and the juveniles can't fly yet.
I met the police officer of the island and pointedly asked him when was the last time he had to deal with crime.
"Crime... crime... let's see." he said, counting on his fingers slowly "Umm... seven years ago there was a domestic violence report because a tourist slapped his wife in an argument."
The hotel doors have no locks. There's $500 in cash in a tin next to a shack full of equipment on the beach with a "honesty system" rental price list sign next to it. The bloke selling you coke cans at the milk bar bought it with the $20 million he made in the stock market. Half the tourists go there by private plane. Ballmer's son took his super yacht there with a harem of models. And on, and on.
If you ever get the opportunity to visit: GO!