Posted by move-on-by 1 day ago
* https://data.iana.org/time-zones/tzdb/backward
If one traces references, one finds this connected bug on Launchpad. Amusingly to anyone who has ever seen these sweeping timezone database changes over the years, Launchpad marked it as "This bug affects 1 person.".
* https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/200807...
The rules for the "backward" file are here:
* https://data.iana.org/time-zones/theory.html#naming
All of the US/* timezone names, such as US/Pacific here, have been backwards compatibility measures in place for the whole of the 21st century and some of the late 20th. The Olson database in the 1980s (mod.sources v08i085, comp.sources.unix v14i030) used these names. But the naming scheme changed somewhen in the 1990s to a continent/city and ocean/city form and backwards compatibility with the old names has been preserved ever since by the "backward" file.
* https://groups.google.com/g/comp.unix.solaris/c/ON_MPZxVdv0/...
Debian has moved into a non-depended-upon package a backwards compatibility measure that is as old as Debian itself.
That just means no one has clicked "affects me too" button yet (after logging in).
US/* was moved to 'backward' (the file for backward compatibility) in the tz database in 1993(!) and as such was essentially marked as deprecated long enough. https://data.iana.org/time-zones/tzdb/backward
You're telling me you didn't notice ? It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.
In a large fraction of cases in the FOSS world, it comes across that the developers really do want to communicate this sort of thing, but there's no clarity on where or how they should do so. See for example various deprecations in Python packaging tools (and standards).
* https://data.iana.org/time-zones/tz-link.html#tzdb
* https://web.cs.ucla.edu/~eggert/tz/tz-link.htm#tzdb
Paul Eggert explained the continent/ocean plus largest city naming convention on a WWW page almost a quarter of a century ago. The WWW page was so well publicized that you can find its URL baked into at least four of the O'Reilly animal-cover books from the early 2000s.
* https://web.archive.org/web/20011023074744/http://www.twinsu...
It was explained on Usenet and on mailing lists prior to that.
An example of this falsehood? Well, in the 70s my father convinced most of my hometown, at least the portions between Main St and Wharf, that DST was absurd.
For almost an entire year, this was observed.
Do you think they kept record in tzdata? I tried to convince them, but no! I still have some dateplanners my father had printed up, and even a picture of the sign that was out on the road (to alert visitors!).
But no!
Do not trust the tzdata people. As you can see, they are not so accurate.
I frequently kick myself for losing track of that book.
> "The tz database is not authoritative, and it surely has errors. [...] Errors in the tz database arise from many sources: Sometimes, different people in the same city maintain clocks that differ significantly. [...] Even if the time is specified by law, locations sometimes deliberately flout the law. [...] Any attempt to pass the tz database off as the definition of time should be unacceptable to anybody who cares about the facts."
Nobody can really find fault with Asia/Jerusalem, whereas either Israel/Jerusalem or Palestine/Jerusalem would be controversial.
I had another issue during my upgrade to Debian 13 that also wasn't mentioned in the release notes. I filed a bug report, but I was told that the issue was not important enough to put in the release notes, and I should have instead more closely read NEWS.Debian of the package. So I don't really know anymore what the "Issues to be aware of" chapter in the release notes is for, because apparently it's only a small selection of issues you need to be aware of.
The operational upgrade failure is if you have any existing drop-in config that sets `server_tokens off` already a hard fail Nginx error about duplicated keywords will occur, causing the apt process to exit with failure code(s) during the standard upgrade process.
[1] https://github.com/nginx/nginx/blob/master/conf/nginx.conf
* https://packages.debian.org/source/sid/nginx
* https://salsa.debian.org/nginx-team/nginx/-/commit/3e7838a6b...
* https://salsa.debian.org/nginx-team/nginx/-/merge_requests/8...
(There is a tool to convert the old configuration syntax to the new, but it requires a working installation. There is a command line option to enable support for the old format, which if nothing else helps to be able to run the conversion tool, but there's no information how to enable that command line option in the way Debian starts pdns-recursor.)
timedatectl list-timezones
For your convenience, here is a list for a Debian 13 box with 628 entries:
https://pastes.io/output-of-timedatectl-list-timezones-on-de...
https://gitlab.com/gitlab-org/gitlab/-/issues/556779#note_26...
The fix is simply to change them to the non-backwards linked names but it caused some confusing API errors since data which would no longer pass validation was already in the database and didn’t look wrong.
- Debian 13
- Interactive Brokers' Trader Workstation
- Racket's `gregor` date and time library
IBKR still sends the old, deprecated US/* timezones. As noted in the article, the solution is to `apt install tzdata-legacy`.
I wouldn't expect to see all the important news of the tens of thousands of packages I don't have installed in the release notes.
I was hit by this using unstable (before they made a NEWS item), but when upgrading my stable machines to trixie I got a proper warning/reminder of this specific thing.
0: Note that different cultures disagree on whether there are two continents called North America and South America, or one continent called America.
> At the time, I went "WTF?" and just commented it out to get it running again. I had bigger fish to fry... and just kind of forgot about it. Everything seemed fine.
I get this, but now you get to laugh and dust yourself off. If it had silently started doing the wrong thing, that would be a worthy complaint.
But they explicitly or implicitly have also decided not to store the timezone in the strings, so every single value is technically ambiguous. Absolutely drives me crazy.
Update: since there have been questions, these are strings, not native datetime values.
You have to make certain it is always handled as UTC, and if you export it to another system without making the timezone explicit, or anyone who is unfamiliar with the convention views it, you’ve lost the guarantee.
When you’re shuffling around petabytes of data, adding another few megabytes to include the “Z” at the end of every timestamp is hardly a major expense.
Not sensible at all for future date/times.
(That's what I heard anyway)
On the other hand, UTCx timezones are not silver bullets if your fleet is a part of a multi-continent federation.