Australia/Lord_Howe is the weirdest timezone
ssoready.com
ssoready.com
The commit message at https://github.com/eggert/tz/commit/b22d459a367f4d01b10f6f6b... says:
> For example, Glib computes Sao Paulo time stamps as if Brazil's circa-1913 rules were still in effect. (Thanks to Leonardo Chiquitto for reporting the bug.) Work around the bug by not generating time stamps equal to -2**63. Come to think of it, time stamps before the Big Bang are physically suspect anyway, so don't generate time stamps before the Big Bang.
Soon afterwards, a separate commit disallowed leap seconds before the Big Bang.
But i can not find it anymore. Anyone has an idea ? Is it gone completely?
Two different calendar systems are used, Gregorian and Julian.
These are nearly identical systems with Gregorian making a small
adjustment to the frequency of leap years; this facilitates
improved synchronization with solar events like the equinoxes.
The Gregorian calendar reform was introduced in 1582, but its
adoption continued up to 1923. By default cal uses the adoption
date of 3 Sept 1752. From that date forward the Gregorian
calendar is displayed; previous dates use the Julian calendar
system. 11 days were removed at the time of adoption to bring the
calendar in sync with solar events. So Sept 1752 has a mix of
Julian and Gregorian dates by which the 2nd is followed by the
14th (the 3rd through the 13th are absent).
Another way to put the bug outcome is: "Instants before the Big Bang are out of scope of this library, so if an algorithm produces incorrect values, but only before the Big Bang, the algorithm is acceptable and does not need to be improved/replaced."
Separately, I'm a little skeptical of the tzdb's endeavor of even thinking about pre-Unix-epoch stuff. The bug-to-utility ratio of that stuff doesn't seem to be there. `zic` is where most of the ugly gnarliness of tzdb lies, and I sometimes feel that it would have been better if `zic` weren't an artifact others could depend on.
Or, for something a bit more agreeable: genealogy (esp. the bioinformatics queries in genetic genealogy) needs a good, high-resolution timeline to normalize events onto. Actually, the non-genetic kind of geneaology, solves a lot of vagueries in lineage as constraint-based puzzles over (local!) dates, with razor-thin margins that would be messed up without correct timezone-based calendar conversion — constraints like "two people couldn't have been related as mother and child, if the mother died at least two days before the child was born."
Even if you mandate that wallclocks agreed everywhere on Earth, everyone would need a replacement to know when someone is likely to respond: Is it too late to call Grandpa? and: When should I schedule this business meeting?
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).
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.
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.
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.
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?
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/Ethiopian_calendar
The Ethiopian calendar has twelve months, all thirty days long, and five or six epagomenal days, which form a thirteenth month.
I like that Tolkien’s legendarium got the first mention here though.
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!
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.
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.
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.
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.
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.
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.
With about 13 hours of sunlight in the summer, split evenly around the mid-day, it comes down to 05h30 to 18h30 under light. There are many more people who would be out there to enjoy the sunlight between 18h30 and 19h30 than there are between 05h30 and 06h30.
Sunlight in the morning is useful. It's better for your sleep rhythms. It's safer for school children, etc.
And to be completely fair, I don't see that many more people "enjoying the sunlight" during the weekend when they have the entire day to do so. Like, what is the sun going down at 6 really preventing you from doing that you couldn't do otherwise?
So they don't want Daylight Savings Time to make it end even later than it already does.
It's also because of the fast day of Yom Kippur - people wanted the faster to end 1 hour earlier.
So they wanted DST to match up to those days - but that made the DST period too short, and led to the negotiations.
On July 8, 2013, the Knesset approved the bill to extend IDT even further. According to the bill, IDT will begin on the Friday before the last Sunday of March, and end on the last Sunday of October.[14]
This is not true. Someone already noted that Raku supports leap seconds. I think this may be partly my fault, because Perl 5's most popular datetime library, `DateTime.pm`, supports leap seconds.
It's my fault because I created `DateTime.pm` and implemented its leap seconds support. In retrospect, this was almost certainly a mistake. Almost no one cares about leap seconds. It just produces all sorts of weird confusion. Like why does adding 60 seconds produce a different result than adding 1 minute, but only rarely?
And it makes the code _way_ more complicated, especially since I wanted to validate whether setting second to 60 was valid.
This seems simple. Why not just look up the leap second table and check? Well, the `DateTime` constructor takes time components (including `second => 60`) and _any_ time zone. So we have to convert the date/time passed to the constructor to UTC in order to do that lookup. But doing that conversion ... ended up involving values that include leap seconds because of historical reasons.
It's a huge mess for very little gain.
As to Raku, I think it's stdlib datetime library borrowed from Perl 5's `DateTime.pm` quite heavily so it inherits some of the same bad design decisions.
What was the thought process originally? Were you just too focused on the problem?
I find that if I'm too close to the problem and too focused for [arbitrary timeframe], this is the type of thing that happens. The joy of fixing something before it's broken takes over.
Of course, the _real_ correct solution is to split up a date/time library into a number of closely related classes/structs, and allow users to pick the one that meets their needs. So most folks would pick the leap second-free class, but a few would use the one with leap seconds baked in.
"An Instant is a particular moment in time measured in atomic seconds, with fractions. It is not tied to or aware of any epoch."
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.
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.
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.
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...
> 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).
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.
If your comment was about the 2019 change that almost all computers got wrong, this one was announced with 6 months of antecedence like most others.
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.
In Palestine, this depends on my OS vendor managing to update the tz database in the short window before the official announcement and the decision coming into force. (I believe the tz database makes some assumptions based on past performance, but the government can change their mind any year.) If my OS does not update, I need to change my time zone manually to something that has the right UTC offset, and then I need to manually change back in the autumn, and I can never be 100% sure if any given computer shows the official time.
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.
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.
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.
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
It leads me to wonder. If it's all just an automated and finite offset, there's no reason for daylight savings policies to hew to 60 minutes adjustments.
Couldn't a nation decide to have a continuously changing offset throughout the year? It might make their offset lookup table substantially longer, but this could 'solve' daylight savings time It'd be adjusting all the time and you wouldn't notice, just you don't notice when leap seconds occur.
Those who rely on analog clocks might no longer adjust the same direction each time!
For as long as clock sync for electronic devices has been common, I have suggested to anyone who would listen that we should adjust forward 10 minutes on the first Sunday of each month for six months, and then back 10 minutes on the first Sunday of the other six months. A ten minute change once a month is not only easier to adjust to (almost unoticeable), but if you miss it, it's not as big a deal as being off by an hour would be.
This ignores the easiest solution to daylight savings time.
Stop doing daylight savings time.
My preferred solution would be permanent standard time rather than permanent DST, but I'll take what I can get as long as we stop changing the clocks twice a year.
The only really important assumption not obviously present in TZif's data format is that when you go from a local time to a UTC time, there can only be up to two possibilities. A lot of software works on that assumption, for instance java.time.LocalDateTime has a withLaterOffsetAtOverlap():
https://docs.oracle.com/javase/8/docs/api/?java/time/LocalDa...
That implicitly assumes that whenever it's ambiguous what 2:30AM means, you can only have two possible solutions (pre- and post-DST). If a timezone were ever to manipulate its offsets so that there were three or more solutions (such as if they did a "fall back" at 2:00AM and then 2:15AM or something), a lot of stuff would be unable to represent that.
It would mean that the repeating meeting time would be at a slightly different local time every week.
Other than considering current legally defined timezones as "legacy" definitions and then removing them for no reason other than to follow European fashion.
So, flexible, but managed by inflexible university types.
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!
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.
Instead of picking the timezone with the correct offset and no DST, many people would adjust the time itself so the wrong timezone and the wrong unixtime cancel each other out so the clock "looks right". Not fun when you're doing math with timestamps, some of which are local and some come from the server.
This one appears to have been published in the summer of 2024.
"Summer" in certain parts of the world, at least.
Thanks for the fun and informative blog post!
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).
1. Date and Time Programming
2. Debugging
You will encounter every possible issue and common bug when doing #1, leading naturally to #2.
Raku supports leap seconds. see https://docs.raku.org/type/Instant
It is correct that Greenland is part of Denmark, and Denmark is a member of EU. But Greenland voted several years ago to stay out of the EU.
Greenland is still part of the EU’s overseas countries and territories. It’s not like it’s in a different universe.
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.
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.
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?
Eh? Most of the world don't do summer time.
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).
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 :-)
[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019716
There would be cultural effects as people in California now start work at 16:00, for example...
How do you handle the date changing in the middle of the day? If I was on UTC, the date would change at 5pm. Is that still Wednesday or would it be Thursday?
Also, it doesn't solve the problem since still need to figure out local time when interacting long distances. If need to keep track of local times, might as well use time zones.
Finally, can solve most of the problems with time zones by including UTC time with anything long distance. Say "meeting is at 4pm, 23:00 UTC", then nobody has to worry about your local time zone.
Try selling East Asia and Australia on the idea that they should wake up at 7pm, go to work on Friday, finish their workday on Saturday, and then go to bed at 11am -- for the benefit of people on the other side of the world who can't be bothered figuring out local time.[0]
Will it fix software issues around time handling? Why not, I'm sure things like having trading days on the Hang Seng stock exchange that run over overlapping two-day periods (the Nov 11-12 trading day, the Nov 12-13 trading day, ...) won't cause any unexpected issues at all. Quick, what's T+2 settlement for a trade on Nov 12?
And how would Europeans react when the global majority vote to move the suddenly-meaningful Prime Meridian to much more populous and economically important regions than London, and it's now Europe that gets to experience that kind of day, for the benefit of Tokyo and Beijing?
[0] Not to mention, 'global time' won't help with scheduling at all, since the question "what time is it there?" just gets replaced with "when do they work and sleep there?". 10am local time gives you actionable information about whether people in a given place will be awake or not, 10am 'global time' does not.
BIT (UTC-12) is better. Only positive offsets. Everyone on the same day.
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.
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.
It is a system of time for saving daylight.
It is not a sales event promising “savings.”
Frustrating to read an otherwise excellent and detailed article that makes this error throughout.
https://en.wikipedia.org/wiki/Daylight_saving_time#Terminolo...
BTW. A long, informative post without a single mention of AI. A rare thing these days.
There's UTC+14 in Micronesia: https://en.wikipedia.org/wiki/UTC%2B14:00
Also Antarctica/Troll: A timezone for a norwegian research station. https://en.wikipedia.org/wiki/Time_in_Norway
I found this pretty funny, but a spot on solution. The solar/calendar features of Emacs are surprisingly robust and easy to work with.
https://devblogs.microsoft.com/dotnet/handling-a-new-era-in-...
(The #10 slot varies according to source, but in general, Houston #4, San Antonio #7, Dallas #9, Austin #10. Fort Worth is nearly tied with Austin. Some sources claim Jacksonville, FL is #10, but they must be wrong...) :-)
> Don’t let people bully you into thinking that just because something is complicated, it’s impossible. > This is because almost every standard (except ISO8601, whatever) is just a file, and you can read it.
In context, (my interpretation is that) "standard" includes things like The Time Zone Information Format [1], the GNU docs about TZ [2], etc. I think the idea is to say "the documents laying out the details of complicated things are still just documents, you can read them if you're interested and don't have to just see them as meant of domain experts. Some of them have barriers to access like the ISO documents, but even excepting those you have direct access to most everything you might want to understand, don't let the idea of standards intimidate you."
[1] https://www.rfc-editor.org/rfc/rfc8536.html [2] https://www.gnu.org/software/libc/manual/html_node/TZ-Variab...
You might find most standards for ~20 USD, but ISO8601 direct from iso.org will set you back 173 CHF (~200 USD) for part 1¹, 194 CHF (~220 USD) for part 2². For $20 you get only the latest amendments from them.
Meanwhile the Estonians will gladly sell you their version of part 1 for just under 30 USD.³
¹: https://www.iso.org/standard/70907.html
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 !
https://www.atlasobscura.com/articles/the-extreme-daylight-s...
If there was a Hall of Fame of OSS contributors - you would be in it sitting on top of a mountain. The Time Zone problem is a unique problem in that its not just a problem of whats the time in this location - its what was the time in this location 20, 50, 100 years ago. The level of scholarship and historical research you put into this library is really quite unmatched. Amazing folks you two. The whole world quite literally sits on the shoulders of you two giants.
“Daylight Saving Time was first suggested as a joke by Benjamin Franklin in his whimsical essay “An Economical Project for Diminishing the Cost of Light” published in the Journal de Paris (1784-04-26). Not everyone is happy with the results.” - Paul Eggert
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’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.
Which is not an acronym, btw, it's just styled in all caps, and is to be pronounced "iso" rather than "eye-ess-oh".
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].
Snake Emoji Kanye vibes are the weirdest timezone.
Something about this doesn't make sense. My understanding is that Ramadan can happen at any season of the year (imagine fasting all day in Greenland during the summer!) because the Islamic calendar doesn't insert intercalary months like many other "lunar" calendars do. Given that, what is the benefit of having a daylight savings time at all if it's tied to the lunar calendar? Isn't the idea of DST tied to day length?
(Or did you ask something else entirely? It wouldn't be the first time I misunderstood things about time zones.)
[1] https://tidepool.stoplight.io/docs/tidepool-api/branches/mas...
https://en.m.wikipedia.org/wiki/Longitude_(book)
It's generally pretty well-regarded and closely related.
Historically there was also Dublin mean time (UTC -00:25.21) and Warsaw mean time (UTC+1:24)
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.
Timezones are fun...
> The tz database predicts future timestamps, and current predictions will be incorrect after future governments change the rules.
Why not switch to a normal 60 minute offset to UTC?
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.
Well, C23 mandates a byte is 8 bits, and POSIX 2024 disallows newlines in filename, so we do exercise that right times to times.
Historic data can be recorded. Rules like "last Sunday in October" or "first day of Ramadan" can be implemented and handled automatically (even if the current Unix implementations don’t do non-Gregorian calendars out-of-the-box). But there can be time zones whose DST rules are "if the groundhog sees its shadow, we start DST two weeks later, otherwise, there is no DST this year". Some countries actually implement this, except the groundhog is replaced by your friendly local regime.
>> Oh yeah the OCR on Japanese driving licenses pops out things like “平成 8”, that’s just how they sometimes say 1996 over there. That’s why we have this in the parser: eras = { "大正": 1912, "昭和": 1926, "平成": 1989 }
>> One of these days we’ll need to add "令和": 2019, but it hasn’t come up yet.
Taiwan also uses the ROC calendar[1] which is directly descended from the regnal calendars of imperial china.
But it's quaint that the Japanese name their year after one person, while us enlightened westerners simply use a calendar where it's simply the 2024th year of the, erm, hmmmph...
[1] https://en.wikipedia.org/wiki/Republic_of_China_calendar
I think I actually heard on a podcast that some Mars rover mission team had to operate in shifts that were synchronized with Mars days.
Time according to timezones measures the position of the sun. Except when we clearly decide with daylight savings time that we don’t care about the position of the sun, we just want it to be a certain time.
When the sun is directly over NYC it is usually 1pm or 2pm, depending on time of year, but 5pm or 6pm in London. Why? Are these events happening at different times? No, they are happening at the same time. Why do we use a different number for them?
Your “time zone” may decide that generally the workday is from 14:00 to 22:00. Why not? We already have second and third shift workers, so the idea of 9-5 is dead anyways.
When I schedule a meeting with someone in Tokyo and I am in NYC, is the meeting not happening at the same time? Wouldn’t it be easier to say “let’s do it at 13:00”? We still would need to figure out if people are awake and at work but we have to do that now while also figuring out daylight savings, so not only time but day of the year matters.
Heaven forbid you schedule a meeting or an event or a delivery or a stock trade and your time zone gets helpfully updated after you schedule the thing but before it happens. Better hope all the processes and software get that right or else!
And here is my favorite example I recently encountered: what is the speed of federal laws in the US? Say the tax brackets are rewritten for 2025, starting “January 1”. Cool, so if you work the NYE shift from 8pm to 4am in Chicago, is it the DC timezone that matters for your taxes? The local? If cannabis is legalized starting at midnight but you get arrested for possession at 11pm the day before in LA are you wrongfully detained or did you miss it by one hour?
Timezones are 19th century thinking. We can do better.
U.S. income taxes are calculated on an annual basis, not hourly, so that is not an issue. (Wages are taxed according to when they are paid, which is a specific point in time, not according to when they were earned). A better example is trying to figure which calendar (tax) year an item of income or deduction belongs to. On tax professional forums, there are occasional discussions about what happens if I make a business payment online just before New Year's Day begins, but the recipient doesn't "constructively receive" it until after (or similar scenarios involving time zone differences). Do I get a deduction for the old year, but they have income in the new year? (The best answer, of course, is to not wait until a few hours before a deadline to conduct business transactions of this type, but not every type of business has that choice available).
That's why I only use Swatch™ Internet Beats [1] for timekeeping.
Now if you'll excuse me, I have a @583.32 meeting to get to.
So in UTC-5 the day would end at 19:00 solar time. „Lets meet up for dinner on Thursday“ would become completely ambiguous, depending on the time. If you move dinner on Tuesday at 18:30 (23:30 UTC) to an hour later, it would be on Friday at 0:30 UTC.
Common types calendars would become quite useless, they would need to be different for each timezone. It doesn’t make sense to split the events of one solar day into multiple day-columns in a calendar.
The vast majority of people plan their life around solar days, they usually don’t have appointments planned that span over two calendar days.
You would have to give up many concepts that have local relevance, while gaining better understanding with non-local interlocutors. I think the balance depends on how many of your daily interactions happen at local or non-local scope.
Swatch tried it in the 90s and failed. Maybe we are more globalized today...
It's a social problem and it calls for a social solution.
I know, there's a lot of disagreement around where the point in question is, but it would serve us well if more engineers were more assertive about stating their opinion on where it is.
We would need to form some kind of global union and push back together.
Instead, the authors prefer to use their own domain language — source files with a compiler to a binary format with a reference parser implementation. The thrust of this article is that’s mostly good enough but their domain language doesn’t include lunar information.
The downside would be size and runtime efficiency. I’m guessing tzdata is built the way it is so that it can be extremely small and efficient rather than large and, computationally speaking, comprehensive. You can run it on an Arm M0 as well as an Apple M2.