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.
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.
Absolutely agreed, it’s a really nice conversational tone. It is technical without being dry and entertaining without watering down the information. I strive to write like this.
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.
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.
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.
The great thing about Australia/Eucla is that it’s not officially gazetted, and yet there are road signs informing travellers about it. I love that people just do it and everyone goes along
I mention Asia/Kathmandu instead of Pacific/Chatham or Australia/Eucla mostly because it's not one of those "exotic birds / kangaroos outnumber humans 5:1" kinds of places.
> 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.
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.
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.
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.)
I bet it's North America bias—we roll our time changes across the continent one TZ at a time, at 2am local time (which also explains why the default is "/2").
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?
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?
Yes, it is, because in your phrasing the fact that nobody else keeps time that way is the cause and lack of support in software the effect. The comment that I originally responded to is phrased as though lack of software support is the cause of weirdness.
I object to the latter since software is not the source of truth, the social practices it aims to encode are. It is perfectly reasonable to say that this particular practice is so rare that it is out of scope, but this makes tzdb a not quite correct approximation of reality, rather than reality an approximation of tzdb.
Individuals are full of conflicting incompatible desires and people as they group are exponentially so.
There are people who want to end any other human to ever live homeless in starvation or any kind of poverty and there are people who want to eliminate anyone they judge as threat or a nuisance while reinforcing there feeling that they dominate everything that will ever matter in the world and the rest.
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.
I agree with that take. It's also quite different from saying that it's weird because software doesn't support it, which is the claim I took issue with. Maybe I should've phrased my comment differently.
Not necessarily. To be inexpressible in software, all it has to do is be unpredictable; it can still be boring.
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.
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...
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.
> 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!
Mechanical clocks in Japan were designed to handle those situations:
> Adapting the European clock designs to the needs of Japanese traditional timekeeping presented a challenge to Japanese clockmakers. Japanese traditional timekeeping practices required the use of unequal time units: six daytime units from local sunrise to local sunset, and six night-time units from sunset to sunrise.
Look where the sun is, remember where it is at sunrise/-set (much easier if you're outside every day) and then mentally divide the sky into segments and just ballpark it.
You'll find the ancient interpretation that the new day starts at sunset still in religions. Sabbath starts on Friday evening, Easter and Christmas day start on the eve of the day before. Possibly the Eids of Islam too, but I'm unsure.
Ethiopia is one of the ancient Christian countries, the second of officially convert and the Ethiopian Ortodox Church still seems prominent. I assume that's the reason why.
Possibly simpler to explain that it is just an artifact of using sun dials for timekeeping. Sun dials technically only can tell time accurately during daylight and base-12 is an easy division of a dial (circle).
It's not odd as in a more unusual system, but odd in that it is widely incompatible with the calendar of most of the world, but still official calendar. Kinda like the Kodak calendar (which was instead 13 28-day months (364 days), and iirc does the off-day adjustments over the corporate winter holiday...actually pretty reasonable)
There are good reasons for the Gregorian calendar’s oddities, though. Any simple system stops being simple when you apply it to enough different situations. I am not sure programmers would like it better if each country had a different calendar for each season. Because a day that starts at 6 and ends at 18 would make sense 2 days each years here in Europe. Not even that if you go far enough North.
The west inherits from the Romans, and Julius Caesar standardized away the Roman intercalary month by glomming it into Feburary. Before that a "priest" (the pontifex maximus) (in scare-quotes because it was a political office) would add that month on an ad-hoc basis. Not so different!
This is common across East Africa, including Kenya where I’m from. The night ends at 6:00AM, with 7:00AM being saa moja (first hour) of the day. Similarly, the day ends at 6:00PM (thenashara). Intuitively, this clock makes much more sense than the English clock. There’s rarely confusion between times because it’s embedded in the language.
What time is displayed on your phone when you are in Kenya? Is there a setting to make it display the commonly used time rather than the official time? I'm going to Kenya next year and I'm excited to see how my phone behaves.
This is indeed a more logical clock, as it follows the natural cycle of activity. Equally, calendars that put the end of the year at the time after harvest ("autumn"), or at the start of agricultural work ("spring") are also more logical.
Positioning the beginning of a new day at noon, and a new year t a solstice, is just a technical convenience, because these are easy to detect with very simple astronomy tools.
What makes it more logical? The wheel turns all the same no matter where you mark the beginning. In the Northern hemisphere, there's actually something nice about starting the year in the dead of winter: it feels like the year is born in the spring and then dies away the following winter, not unlike a lifetime.
The year "dies" on the longest, darkest nights. (Dec 21, technically). We mourn its passing and celebrate it's life with drinks. I'm guessing there was in antiquity, a whole bunch of dreadful and exciting parties in the last 10 days around the longest nights.
January 1 is so close to December 25 (when Jesus is believed to have been born) so if we wanted to count years since that -- and call it AD for "Anno Domini" (the Year of Our Lord) -- we could declare the year to begin on January 1st.
A lot of people believe a lot of things. I wonder why you don't believe that people believe this.
Now whether you yourself believe he was born then, another time or ever existed at all etc is another story.
I believe for example that everyone can believe whatever they want about those things as long as:
They leave me alone when I tell them I don't believe that and I don't want to be convinced
They don't try to kill me, enslave me, etc for being an infidel (yes that includes the Christian holy wars sort of thing but also current events)
To restate more precisely: It is well-established that December 25 is a highly unlikely date for the birth of Jesus.
Children and people who have only a superficial knowledge of Christianity might very well believe otherwise. But they are poorly-informed.
Arguments against include:
a) Calendar dates are generally fuzzy from that period, particularly for events that are not formally documented. So the likelihood of anyone ever having known the correct date is very low.
b) The mythology around the birth does not match the seasonal expectations for late December (more likely springtime).
c) Dec 25 was chosen in 336 AD, by church decree. Prior to that, there was no holiday nor even a strong claim of any specific date.
d) Dec 25 was already a festival day for pagan celebrations of Saturn (Rome) and Mithra (Persia), which was likely a factor in the choice of date, to coincide with existing customs.
There are no substantial arguments in favor of December 25 being the accurate birth date of Jesus.
I don't think anyone is arguing that December 25 is the birth date of Jesus (assuming he existed), the argument is just that there are people who believe it is. You seem to think only children and people who don't know much about Christianity would believe that, but I assure you there are lots of Christian adults who don't know the history you (correctly) laid out.
when in fact, yes, people do actually believe this.
When this is pointed out, he explains why it can't be Dec 25th and that's all totally fine and correct but doesn't change the fact that yes indeed there are people that believe that, as well as lots of other things that can easily be disproved. It does not matter whether you can disprove it to us and others. These people that do believe it are in fact out there.
January 1st became the start of the year about half a century before Jesus was born.
25 of December is close to the winter solstice (around 22nd), and I suspect it was ascribed to that day for astrological reasons; there are a few other astrological clues around that episode, most prominently, the Bethlehem Star.
If you DO start in March, your days/month fall into a neat little pattern:
Mar 31 - Aug 31 - Jan 31
Apr 30 - Sep 30 - Feb 28/29
May 31 - Oct 31
Jun 30 - Nov 30
Jul 31 - Dec 31
That highlights a few interesting cycles you can use to calculate dates from a simple count of days from the start of the year:
153 days every 5 months
61 days every 2
31 days per month
An "early reset" occurs every second month, jumping to the next 2-month cycle after the second day 30. Another occurs after every fifth month, jumping into a new 2-month cycle halfway through the last one of the 5-month. And of course, end of the year breaks the third "5-month" cycle WAY early, just before even its first 2-month is finished.
I won't try to detail the process of generating dates from this here, but I'm sure most of us here can work it out with just a little effort. Instead, here's a couple more fun facts to consider:
If you DO start the calendar from March, counting it as month 1, September (7) through December (10) map rather nicely to their own numeric positions. That seems a pretty strong hint, to me.
And I REALLY love this one:
The Gregorian cycle consists of four centuries. The first three are 36,524 days each: 100 years x 365 days + 24 days for the leap years. The hundredth year (ending in 00) is NOT considered a leap year, EXCEPT for every FOURTH hundredth. So that's 4 centuries * 36,524 days = 146,096, plus 1 more for the leap century, for 146,097.
That number is EXACTLY divisible by 7, which means the week cycle repeats WITH the Gregorian one. Good thing! Otherwise, we'd have to wait 2800 years!
- months are counted as 3, 4, 5, ..., 14, with 13 and 14 being January and February of the following year
- the contribution of the month to the day of the week is floor(2.6 * (m+1)) - the 2.6 comes from the 13 "extra" days (over the approximation 1 month = 4 weeks) in every 5 months.
March was the beginning of the year not all that long ago.
That's why there frequent confusion about George Washington's birthday, along with other historical dates of that era: The New Year started in March when he was born, but changed to January during his lifetime (The British Empire switched in 1752). So being born in February, there's an ambiguity about the year, unless you specify which calendar you mean:
"George Washington was born on February 22, 1732, according to the Gregorian calendar. However, when he was born, the Julian calendar was in use, which would have placed his birth on February 11, 1731."
Of course, and -- if you were Roman, for instance -- you could, for example, call the 8th month a name with "octo" (Latin for "eight") in it, or the 10th month something with "decem" (Latin for "ten").
The whole lives of the societies which have actually invented these calendars were built around the vegetation cycle, which ruled pastures, fields, and orchards. So the yearly cycles of food availability, work, seasonal migrations, and the correlated weather pattern changes were all reasonably aligned with the start / end of the year.
Peoples as diverse as Celts, Romans, Slavs, Babylonians, Hindus, and various peoples in China all used a variety of a calendar where the yearly changes were aligned around modern October-November and modern March-April.
A calendar with the year starting in January and with astronomically (more) precise years was promulgated by Julius Caesar in -46. (I suspect the introduction of the concepts of Babylonian astrology to Rome a century before may have played a role in the desire to align the calendar to stars and not to earthly affairs.)
Positioning of the new year at the Equinox shouldn't be any harder than doing it at the solstice (since equinoxes are halfway between the solstices), and it makes much more sense IMO. First half of the year: more day than night. Second half of the year: more night than day.
Of course not. Gregorian Calendar didn't drift, it just fixed drift in Julian calendar, which was like a couple of weeks by 1582. And "new year" in Julian calendar was 1st of January, same as now. It was inherited from previous Roman tradition, because Romans already had the custom to mark 1st of January as a new year, because since 153 BCE it was the date when consuls were inaugurated. So it's an entirely political thing and makes no real sense whatsoever. We are celebrating the day of Roman consulate inauguration for more than 2000 years now.
And before that they they started years from 1st of March, which is much closer to one of the Equinoxes, which is what all sane people (including french revolutionaries) consider to be the proper start of a year.
Only if everyone is a peasant farmer with the same crops in the same place. My activities are barely related to the height of the sun in the sky, and like the other residents of my city I don't take a ton of notice of harvest time. Bus timetables and cultural festivals are a much bigger deal (of which one in particular is indeed historically related to a harvest).
My first thought as well as a swede. And coincidentally one of the things my old Kenyan classmate found the most strange about Sweden was the fact that the length of day was not even close to constant. That and when I explained to him that the sun being up doesn’t necessarily mean warmer weather, in the winter it’s practically takes the temperature further from zero as sun means no warming clouds…
The problem with "more logical" here is that it's completely subjective.
The beauty of the "English clock", which isn't English at all, is that it simply defines a way to refer to the same point in time with a number (never mind that Daylight savings" nonsense) and you can refer to it whether you are a farmer, a software developer, a waiter, you live Africa or the arctic circle all the same.
Since it's pretty much on the Equator it makes a lot of sense to keep time like that -- days and nights have the same duration all year long. Such a system doesn't make sense for places that have wide variations between seasons, unless you also alter the length of the hours to match (which I think was done at some point somewhere in Europe, but I can't find any references)
Even on the equator, sunrise and sunset times will vary by +/-15 minutes, because solar days are not of equal length. But yeah, close enough for imprecise use.
Morning and Afternoon are used for AM and PM, or if you want to be really specific you can use the name of the hour, for example 10 am is called barqo, and 18 hours is called himhimmow
Of course. That doesn't mean they are not familiar with the local traditional system though. They just can use both, as in many other countries such as Japan and China and in the Middle East for example.
Intuitive is a synonym for "what one is used to", so I believe you when you say that according to your intuition, what you're accustomed to makes the most sense.
In a place with considerable skew in daylight hours between the summer and the winter, this would be quite unintuitive, because daylight hours would become longer (and night hours shorter) during winter and spring, and the opposite for summer and autumn.
Either that, or a fixed conventional notion of "dawn" which only corresponds to the sun rising around the Equinoxes. Either way would be unintuitive.
Traditional Japanese timekeeping kind of did both. The "am" and "pm" time periods started at midnight and noon, but the clocks themselves started at dawn. The hours counted down from hour 9 to hour 4 (they did not use 3-1). Each of the hours was approximately two modern hours, but their individual lengths changed every two weeks to keep the periods aligned with the sun. The twelve hours on the linear clock dials ran: 6,5,4,9,8,7,6,5,4,9,8,7 (and then a final 6 to match the first six, since it was a linear instead of circular dial).
Wow, this is great! This is exactly how Ive thought times should be done. Ive always called it “local sunrise time”. All the advantages of DST without the biannual spikes in traffic fatalities.
Interesting. I propose that the transition between AM and PM should happen right in the human-sensible middle of the day. If most people start their daily activity around 6, and retire by by 10pm, then the middle would be 14hrs.
This would also give a nice 3-part division to the day that matches their use: 1st 8 hours for the morning, next 8 hours for the afternoon, and the next 8 hours for evening/night. Currently, morning alone is 12 hours, and afternoon is like 6 (or less) and the evening takes the rest.
But I guess the current noon time is chosen for when the sun is highest in the sky, so maybe to preserve noon as the transition point, morning should start from 4:00 hrs, then the afternoon starts from 12:00 hours, and evening would start from 20:00 hours.
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.
> 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.
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.
Not quite a moon base, but for Muslims on the ISS:
> the Malaysian government called a gathering of 150 Islamic legal scholars, scientists, and astronauts to create guidelines for Dr. Shukor. The scholars produced a fatwa, or non-binding Islamic legal opinion, intended to help future Muslim astronauts, which they translated into both Arabic and English. They wrote that in order to pray, Muslims in space should face Mecca if possible; but if not, they could face the Earth generally, or just face “wherever.” To decide when to pray and fast during Ramadan, the scholars wrote, Muslims should follow the time zone of the place they left on Earth, which in Dr. Shukor’s case was Kazakhstan. To prostrate during prayer in zero gravity, the scholars stated that the astronaut could make appropriate motions with their head, or simply imagine the common earthly motions.
I’m not an Islamic scholar (or a Muslim at all), so this is just speculation, but my guess is that if it were a permanent settlement, with people being born and living their whole lives on the moon base (so “where they left earth from” is not meaningful), they’d probably just settle on one permanent Earth time zone to follow; presumably either that of Mecca, or that of whatever country on Earth (if any) owns the base.
Prayer and pointing to Mecca seems pretty simple on the moon - but if Ramadan is based on when you can see the moon, it seems that Ramadan would start as soon as the person in charge walks by a window.
Moon-dwelling Muslims would go by the phases of Earth, if they wanted to match Earth timing but not rely on communication with Earth. The Earth as seen from the Moon exhibits the opposite phase as the reverse. Ramadan would begin when the Moon-dweller sees the Earth as being just past full. If you wanted, you could synch it with a particular timezone on Earth, by watching for when that location on Earth (Mecca or whatever) just rotated past the terminator so it experienced sundown. (Of course none of this can be directly observed if you're on the far side.) (And I get your joke about seeing the moon when you're on it; this is the practical alternative.)
> 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
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 ;-)
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.
And when processing satellite data.. if you're not in agreement of the time, that one second error results in a ~7km geographical error for your typical polar orbit weather satellite.
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.
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!
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.
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)
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 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.
EEST (DST) is UTC+3, EET (without DST) is UTC+2. What Turkey did was abolish the DST transition but stay in permanent DST time or "summer time", which they now call TRT (which is identical to EEST).
There was a survey in parts of the EU a few years ago about abolishing DST that came out largely in favor of abolishing it. In Germany one major source of debate around the issue was that the survey referred to the timezones as "winter time" and "summer time" and predictably more people said they would prefer permanent "summer time". An equivalent survey referring to the timezones as "standard time" and "daylight savings time" likely would have had the opposite result. I could imagine that Turkey picked EEST instead of EET for similar reasons.
Having had a job for six months over the winter where I spent the majority of the 8 hour work day underground, which at times meant I'd go for days without seeing proper sunlight, I agree that this is just miserable.
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.
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.
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)
An interesting aspect of ACWST is that it has no legal status - it's observed purely by local convention, though it's still managed to make it into tzdata.
> 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.
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.
There's a couple of things that made me think the article was way older than it actually is (and made me mildly irritated that it doesn't include the publication date).
First off, the author starts off by talking about GMT and goes on to educate the reader how UTC is actually the current standard. Maybe it's just me but I thought this would be common knowledge by now, while the author frames this as some sort of a revelation.
Then there's the jab about The IERS breaking Wikipedia's css which just doesn't seem to happen on the two devices I opened it on, so I assumed that was the case prior to Wikipedia's redesign.
Minor things for sure, and the content itself is pretty timeless (heh).
Leap seconds are also set to be removed eventually. UTC will become UT1 with a fixed offset, at least until enough seconds add up for the BIPM to care about the offset and insert a leap minute or hour or something TBD.
I'm not sure what you mean, but this sounds wrong. The whole thing about leap second abolishment is to effectively disconnect UTC from UT1, i.e. allow DUT1 to grow unbounded and make UTC a fixed offset of TAI.
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".
For a while (currently?) there was SEO "wisdom" going around about not putting dates on content so that search engines would treat the content as "evergreen" rather than "stale".
Thanks! The irony is not missed on me. I think I have the dates internally in the article metadata, just didn't set up my Hugo templates to display it. TODO!
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).
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.
> 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.
There used to be at least one airport in a tribal area in the US, that had the timezone of the reservation (not same as state) but the DST of the surrounding state (not same as reservation).
Can't remember the code for it now, had a lot of interesting timezone issues in a previous job.
My favorite is the hopi reservation, which does not observe DST and exists entirely inside of the Navajo reservation, which does observe it, and which exists entirely within Arizona, which again does not observe DST, and exists entirely within the United States which does observe DST in the general case.
I'm guessing that the airport was this one maybe? ttps://en.wikipedia.org/wiki/Window_Rock_Airport
Also IIRC (cum grano salis) the federal buildings in the Hopi reservation do observe DST and the state buildings in the Navajo reservation don't. But don't quote me on any of those actually existing.
A fun fact circa 2012 was I was writing a PHP server that needed to talk to a Windows server to schedule things. Windows server used Microsoft's own timezone system, not IANA or anything like that. I went looking for an implementation of IANA <-> MS conversion. I ended up finding all these forum posts by Windows Phone (RIP) users in Arizona who had the wrong time on their phones. So it was nice to know that 1) there was no fixing it and 2) they eat their own dogfood.
> state is really the wrong resolution here, US timezones follow counties
County is the smallest resolution one can reasonably use, but in terms of what timezones themselves follow, that would be metro areas. I.E. the Chicago metro area has its timezone and cities (or counties, if you will) that are part of that metro region, even when belonging to other states that largely follow a different time zone, follow the metropolis’ tz instead.
(Not arguing with you but clarifying the meaning of “follow” here.)
As a young engineer right out of university back in 1985, one of my early tasks involved merging together a bunch of telemetry data provided on mag tapes recorded at different radar sites (in the USA). One or two of the systems time stamped their data in local time, and all the others used UTC. I remember buying one of those old Farmers' Almanacs in order to make an algorithm to account for DST. When I read the rules, I threw up my arms in despair.
The almanac gave nominal rules for the transitions. But there was a footnote explaining that these transitions had and will continue to be adjusted year to year due to Congressional intervention. I showed this to my boss and said, "If I could write an algorithm that predicted future votes of Congress, I would be a billionaire and could quit this engineering job."
I think in the end I coded the algorithm with the recent known transitions, and the nominal rules for future ones. What else could you do (this was before everyone was networked, and the code ran on standalone computers like a VAX).
I also learned that task of merging three sources of tracking data, each with its own validity and measurement degradation status, was an absolute nightmare. But still easier than predicting future actions of Congress.
Yeah you gotta watch out for those "Etc" identifiers, especially if you were thinking about exposing all the identifiers to your users wholesale. The file for them has this comment:
> POSIX has positive signs west of Greenwich, but many people expect positive signs east of Greenwich. For example, TZ='Etc/GMT+4' uses the abbreviation "-04" and corresponds to 4 hours behind UT (i.e. west of Greenwich) even though many people would expect it to mean 4 hours ahead of UT (i.e. east of Greenwich).
> Earlier this year I had to write a function to find the current local time given a US address.
I also did something similar earlier this year, though I used a geolocation service to translate address to lat/long coords, and then used lat/long to translate to timezone. (With shortcuts single-timezone states)
I ended up using this python library for lat/long -> timezone converstion:
465 comments
[ 3.2 ms ] story [ 306 ms ] threadBTW. A long, informative post without a single mention of AI. A rare thing these days.
Snake Emoji Kanye vibes are the weirdest timezone.
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.
https://www.youtube.com/watch?v=-5wpm-gesOY
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?
They used to, railway time is how our timezone system came to be.
Eh? Most of the world don't do summer time.
> 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 think the statement is true by any reasonable metric - population, land area, GDP size.
The only search hits I found for this claim are your comment. I find no such mention at https://en.wikipedia.org/wiki/Indian_Pacific . What are you referring to?
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.
(Or did you ask something else entirely? It wouldn't be the first time I misunderstood things about time zones.)
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
I object to the latter since software is not the source of truth, the social practices it aims to encode are. It is perfectly reasonable to say that this particular practice is so rare that it is out of scope, but this makes tzdb a not quite correct approximation of reality, rather than reality an approximation of tzdb.
There are people who want to end any other human to ever live homeless in starvation or any kind of poverty and there are people who want to eliminate anyone they judge as threat or a nuisance while reinforcing there feeling that they dominate everything that will ever matter in the world and the rest.
Software can help all kind of purpose.
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.
https://en.wikipedia.org/wiki/Roman_timekeeping
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!
Mechanical clocks in Japan were designed to handle those situations:
> Adapting the European clock designs to the needs of Japanese traditional timekeeping presented a challenge to Japanese clockmakers. Japanese traditional timekeeping practices required the use of unequal time units: six daytime units from local sunrise to local sunset, and six night-time units from sunset to sunrise.
* https://en.wikipedia.org/wiki/Japanese_clock#Temporal_hours
Look where the sun is, remember where it is at sunrise/-set (much easier if you're outside every day) and then mentally divide the sky into segments and just ballpark it.
Well, maybe that was another problem with Scotland... ;-)
No wonder they built a few walls and retreated south....
Ethiopia is one of the ancient Christian countries, the second of officially convert and the Ethiopian Ortodox Church still seems prominent. I assume that's the reason why.
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.
1: https://tolkiengateway.net/wiki/Shire_Calendar
I like that Tolkien’s legendarium got the first mention here though.
Sometimes priests moved these days to suit political shenanigans.
Caesar ended this madness and "rationalised" the system, coincidentally making his year-long consulship last for 446 days.
The west inherits from the Romans, and Julius Caesar standardized away the Roman intercalary month by glomming it into Feburary. Before that a "priest" (the pontifex maximus) (in scare-quotes because it was a political office) would add that month on an ad-hoc basis. Not so different!
Positioning the beginning of a new day at noon, and a new year t a solstice, is just a technical convenience, because these are easy to detect with very simple astronomy tools.
Then shouldn't the start of the year be when the year is "born"? Or alternatively, the end of the year when the year "dies"? January 1 is neither.
It slowly grows after that and blooms later.
Which is exactly what we did.
I don't think anyone actually believes Jesus was born on Dec 25.
Now whether you yourself believe he was born then, another time or ever existed at all etc is another story.
I believe for example that everyone can believe whatever they want about those things as long as:
Children and people who have only a superficial knowledge of Christianity might very well believe otherwise. But they are poorly-informed.
Arguments against include:
a) Calendar dates are generally fuzzy from that period, particularly for events that are not formally documented. So the likelihood of anyone ever having known the correct date is very low.
b) The mythology around the birth does not match the seasonal expectations for late December (more likely springtime).
c) Dec 25 was chosen in 336 AD, by church decree. Prior to that, there was no holiday nor even a strong claim of any specific date.
d) Dec 25 was already a festival day for pagan celebrations of Saturn (Rome) and Mithra (Persia), which was likely a factor in the choice of date, to coincide with existing customs.
There are no substantial arguments in favor of December 25 being the accurate birth date of Jesus.
When this is pointed out, he explains why it can't be Dec 25th and that's all totally fine and correct but doesn't change the fact that yes indeed there are people that believe that, as well as lots of other things that can easily be disproved. It does not matter whether you can disprove it to us and others. These people that do believe it are in fact out there.
25 of December is close to the winter solstice (around 22nd), and I suspect it was ascribed to that day for astrological reasons; there are a few other astrological clues around that episode, most prominently, the Bethlehem Star.
Mar 31 - Aug 31 - Jan 31
Apr 30 - Sep 30 - Feb 28/29
May 31 - Oct 31
Jun 30 - Nov 30
Jul 31 - Dec 31
That highlights a few interesting cycles you can use to calculate dates from a simple count of days from the start of the year:
153 days every 5 months
61 days every 2
31 days per month
An "early reset" occurs every second month, jumping to the next 2-month cycle after the second day 30. Another occurs after every fifth month, jumping into a new 2-month cycle halfway through the last one of the 5-month. And of course, end of the year breaks the third "5-month" cycle WAY early, just before even its first 2-month is finished.
I won't try to detail the process of generating dates from this here, but I'm sure most of us here can work it out with just a little effort. Instead, here's a couple more fun facts to consider:
If you DO start the calendar from March, counting it as month 1, September (7) through December (10) map rather nicely to their own numeric positions. That seems a pretty strong hint, to me.
And I REALLY love this one:
The Gregorian cycle consists of four centuries. The first three are 36,524 days each: 100 years x 365 days + 24 days for the leap years. The hundredth year (ending in 00) is NOT considered a leap year, EXCEPT for every FOURTH hundredth. So that's 4 centuries * 36,524 days = 146,096, plus 1 more for the leap century, for 146,097.
That number is EXACTLY divisible by 7, which means the week cycle repeats WITH the Gregorian one. Good thing! Otherwise, we'd have to wait 2800 years!
- months are counted as 3, 4, 5, ..., 14, with 13 and 14 being January and February of the following year
- the contribution of the month to the day of the week is floor(2.6 * (m+1)) - the 2.6 comes from the 13 "extra" days (over the approximation 1 month = 4 weeks) in every 5 months.
That's why there frequent confusion about George Washington's birthday, along with other historical dates of that era: The New Year started in March when he was born, but changed to January during his lifetime (The British Empire switched in 1752). So being born in February, there's an ambiguity about the year, unless you specify which calendar you mean:
"George Washington was born on February 22, 1732, according to the Gregorian calendar. However, when he was born, the Julian calendar was in use, which would have placed his birth on February 11, 1731."
Peoples as diverse as Celts, Romans, Slavs, Babylonians, Hindus, and various peoples in China all used a variety of a calendar where the yearly changes were aligned around modern October-November and modern March-April.
A calendar with the year starting in January and with astronomically (more) precise years was promulgated by Julius Caesar in -46. (I suspect the introduction of the concepts of Babylonian astrology to Rome a century before may have played a role in the desire to align the calendar to stars and not to earthly affairs.)
And before that they they started years from 1st of March, which is much closer to one of the Equinoxes, which is what all sane people (including french revolutionaries) consider to be the proper start of a year.
I live far from the equator - "Dawn" is sometimes after breakfast, and "Dusk" can happen before I get off work.
Then you get above the Arctic Circle, and there are days with neither. :D
The beauty of the "English clock", which isn't English at all, is that it simply defines a way to refer to the same point in time with a number (never mind that Daylight savings" nonsense) and you can refer to it whether you are a farmer, a software developer, a waiter, you live Africa or the arctic circle all the same.
If you live on the 45th parallel like I do, it isn’t logical at all since the length of a day is constantly shifting.
https://en.wikipedia.org/wiki/Equation_of_time
7 AM is 1 Saac ( Hour 1)
6 PM is 12 Saac ( Hour 12)
7 PM is 1 Saac
6 AM is 12 Saac
> 7 PM is 1 Saac
How do you distinguish AM/PM? How does one say that something will happen 19:00 specifically, and not 07:00?
https://digitalcommons.macalester.edu/cgi/viewcontent.cgi?ar...
In a place with considerable skew in daylight hours between the summer and the winter, this would be quite unintuitive, because daylight hours would become longer (and night hours shorter) during winter and spring, and the opposite for summer and autumn.
Either that, or a fixed conventional notion of "dawn" which only corresponds to the sun rising around the Equinoxes. Either way would be unintuitive.
https://en.wikipedia.org/wiki/Nautical_time#Nautical_day
This would also give a nice 3-part division to the day that matches their use: 1st 8 hours for the morning, next 8 hours for the afternoon, and the next 8 hours for evening/night. Currently, morning alone is 12 hours, and afternoon is like 6 (or less) and the evening takes the rest.
But I guess the current noon time is chosen for when the sun is highest in the sky, so maybe to preserve noon as the transition point, morning should start from 4:00 hrs, then the afternoon starts from 12:00 hours, and evening would start from 20:00 hours.
FWIW, the English-speaking world used to switch years on March 25: https://en.wikipedia.org/wiki/Calendar_(New_Style)_Act_1750#...
Neither of these are technically things that tzdb can even talk about. They're concerned with civil time, not calendars or other "reckoning" problems.
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.
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 relation between that time and what the rest of the world thinks the time is is actually less relevant.
https://github.com/google/unsmear
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.
Note to self, look up what Islamic scholars think should be done about Ramadan on a moon base.
> the Malaysian government called a gathering of 150 Islamic legal scholars, scientists, and astronauts to create guidelines for Dr. Shukor. The scholars produced a fatwa, or non-binding Islamic legal opinion, intended to help future Muslim astronauts, which they translated into both Arabic and English. They wrote that in order to pray, Muslims in space should face Mecca if possible; but if not, they could face the Earth generally, or just face “wherever.” To decide when to pray and fast during Ramadan, the scholars wrote, Muslims should follow the time zone of the place they left on Earth, which in Dr. Shukor’s case was Kazakhstan. To prostrate during prayer in zero gravity, the scholars stated that the astronaut could make appropriate motions with their head, or simply imagine the common earthly motions.
I’m not an Islamic scholar (or a Muslim at all), so this is just speculation, but my guess is that if it were a permanent settlement, with people being born and living their whole lives on the moon base (so “where they left earth from” is not meaningful), they’d probably just settle on one permanent Earth time zone to follow; presumably either that of Mecca, or that of whatever country on Earth (if any) owns the base.
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
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...
Especially when, even disregarding the ones with special rules, there's a couple that are 45 minutes off.
Timezones are fun...
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.
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.org/en/time-metrology
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!
Sounds great apart from that bit.
https://www.atlasobscura.com/articles/the-extreme-daylight-s...
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.
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.
There was a survey in parts of the EU a few years ago about abolishing DST that came out largely in favor of abolishing it. In Germany one major source of debate around the issue was that the survey referred to the timezones as "winter time" and "summer time" and predictably more people said they would prefer permanent "summer time". An equivalent survey referring to the timezones as "standard time" and "daylight savings time" likely would have had the opposite result. I could imagine that Turkey picked EEST instead of EET for similar reasons.
Having had a job for six months over the winter where I spent the majority of the 8 hour work day underground, which at times meant I'd go for days without seeing proper sunlight, I agree that this is just miserable.
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
Historically there was also Dublin mean time (UTC -00:25.21) and Warsaw mean time (UTC+1:24)
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.
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...
I found this pretty funny, but a spot on solution. The solar/calendar features of Emacs are surprisingly robust and easy to work with.
This one appears to have been published in the summer of 2024.
First off, the author starts off by talking about GMT and goes on to educate the reader how UTC is actually the current standard. Maybe it's just me but I thought this would be common knowledge by now, while the author frames this as some sort of a revelation.
Then there's the jab about The IERS breaking Wikipedia's css which just doesn't seem to happen on the two devices I opened it on, so I assumed that was the case prior to Wikipedia's redesign.
Minor things for sure, and the content itself is pretty timeless (heh).
I'm not sure what you mean, but this sounds wrong. The whole thing about leap second abolishment is to effectively disconnect UTC from UT1, i.e. allow DUT1 to grow unbounded and make UTC a fixed offset of TAI.
"Summer" in certain parts of the world, at least.
Thanks for the fun and informative blog post!
[1] https://en.wikipedia.org/wiki/Tz_database#Area
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.
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.
Can't remember the code for it now, had a lot of interesting timezone issues in a previous job.
Also IIRC (cum grano salis) the federal buildings in the Hopi reservation do observe DST and the state buildings in the Navajo reservation don't. But don't quote me on any of those actually existing.
A fun fact circa 2012 was I was writing a PHP server that needed to talk to a Windows server to schedule things. Windows server used Microsoft's own timezone system, not IANA or anything like that. I went looking for an implementation of IANA <-> MS conversion. I ended up finding all these forum posts by Windows Phone (RIP) users in Arizona who had the wrong time on their phones. So it was nice to know that 1) there was no fixing it and 2) they eat their own dogfood.
County is the smallest resolution one can reasonably use, but in terms of what timezones themselves follow, that would be metro areas. I.E. the Chicago metro area has its timezone and cities (or counties, if you will) that are part of that metro region, even when belonging to other states that largely follow a different time zone, follow the metropolis’ tz instead.
(Not arguing with you but clarifying the meaning of “follow” here.)
It's worse than that; Malheur County on the eastern border of Oregon is split between Pacific and Mountain time based on whether cities are more economically connected to Idaho or Nevada: https://en.wikipedia.org/wiki/Malheur_County,_Oregon#Time_zo...
The almanac gave nominal rules for the transitions. But there was a footnote explaining that these transitions had and will continue to be adjusted year to year due to Congressional intervention. I showed this to my boss and said, "If I could write an algorithm that predicted future votes of Congress, I would be a billionaire and could quit this engineering job."
I think in the end I coded the algorithm with the recent known transitions, and the nominal rules for future ones. What else could you do (this was before everyone was networked, and the code ran on standalone computers like a VAX).
I also learned that task of merging three sources of tracking data, each with its own validity and measurement degradation status, was an absolute nightmare. But still easier than predicting future actions of Congress.
> POSIX has positive signs west of Greenwich, but many people expect positive signs east of Greenwich. For example, TZ='Etc/GMT+4' uses the abbreviation "-04" and corresponds to 4 hours behind UT (i.e. west of Greenwich) even though many people would expect it to mean 4 hours ahead of UT (i.e. east of Greenwich).
I also did something similar earlier this year, though I used a geolocation service to translate address to lat/long coords, and then used lat/long to translate to timezone. (With shortcuts single-timezone states)
I ended up using this python library for lat/long -> timezone converstion:
https://github.com/jannikmi/timezonefinder
Which sources its data from here, which seems like a pretty high quality source:
https://github.com/evansiroky/timezone-boundary-builder/rele...