10 ms·

Debian 13, Postgres, and the US/* time zones

284 points by move-on-by 1y ago

ggm 1y ago
Is there a problem with ISO3166 denoted information in general or is there a specific US issue here? I would think ISO code denoted tzdata was a public good in some sense.
- evdubs 1y ago
  You can see the zones that are deprecated at https://packages.debian.org/sid/all/tzdata-legacy/filelist https://packages.debian.org/sid/all/tzdata-legacy/filelist
- masklinn 1y ago
  All the legacy time zones were moved out of the default zoneinfo install. It’s not a us-specific issue but the legacy US/ timezones remain in widespread use, and they stop working on Debian 13 ootb (possibly Ubuntu noble as well?).
  - pdw 1y ago
    Are they in widespread use? They were deprecated in 1995.
    - ahoef 1y ago
      I don't see conflict in those statements.
  - pixelesque 1y ago
    Does anyone know why they are still in widespread use? Config defaults somewhere still using them? Man page examples? Tutorials using them? Or just force of habit?
    - rtpg 1y ago
      Some of this is surely just muscle memory or intertia as well. I remember random config values from when I was trying out linux boxes back in high school that I replicated into files that just don't get touched for decades afterwards. When was the last time you rebuilt your company's postgres config from scratch?
      - Symbiote 1y ago
        > When was the last time you rebuilt your company's postgres config from scratch? Last year, when we upgrade to version 17. I looked at the example/template configuration, diffed it with our configuration from PG15, and for every change decided whether to keep our version or the new setting. I didn't use it, but Debian/APT has had a tool to do this sort of comparison for any software upgrade for as long as I can remember. Do other people just copy the old config and shout "YOLO!"?
        rtpg 1y ago
        When your configuration value from PG15 was different from the old default and the new default on something like the statement timeout, and the statement timeout was previously working fine, and obstensibly set for a reason.... I dunno, are you going to question the value that much? And you might say "well I know how a statement timeout works" and I agree! I would also generally agree that something like a timezone setting would generally be something I'd expect to be fairly stable. That's what I meant about rebuilding the config from scratch. Rebuilding from scratch would almost involve _not even looking at the existing configuration_ and then doing first principles footwork to figure out what is needed. I think the diffing flow you went through is the right way to do it, but I believe that flow might lead to some values getting less scrutiny than others. Still perfectly reasonable though
      - magicalhippo 1y ago
        Still typing "nano -w filename" each and every time since back around y2k when I was working on Linux for the first time I was told that bad things could happen if I didn't...
- mananaysiempre 1y ago
  This has nothing to do with ISO 3166 at all. The tzdata database is the work of a single person, Arthur Olson, not a committee (or rather it was, from its birth in the 1980s until 2011 when a company decided to sue him for no reason). And for most of its life it’s been an explicit policy that timezones are named by continent and representative population center, not by country, to avoid entangling it in territorial disputes and improve naming stability for historical data. The US/* (and Canada/*, etc.) names are deprecated and have been since 1995 (?), but apparently people were still using them because the deprecation wasn’t really apparent unless one was especially into reading release notes.
  - breakingcups 1y ago
    Interesting, I hadn't heard about that frivolous lawsuit before: https://www.eff.org/press/releases/eff-wins-protection-time-zone-database https://www.eff.org/press/releases/eff-wins-protection-time-...
evdubs 1y ago
I also ran into this using: - 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`.
raverbashing 1y ago
[flagged]
- rlpb 1y ago
  The timezone names are defined by the Olson database, not Debian. It is the only sensible system in our ecosystem. It certainly beats Outlook which still wrongly insists that my timezone is GMT just because I live in the UK and still confuses everyone (it isn't during the summer; we use BST over the summer, not GMT).
  - raverbashing 1y ago
    Any moderately reasonable system would be backwards compatible and/or migrate existing values > The worst part about this is that it didn't get so much as a mention in the Debian 13 release notes. I read through that document before going for it and never encountered it. Indeed, even now, you won't find "tzdata" or "zone" in it.
    - ars 1y ago
      > Any moderately reasonable system would be backwards compatible It is. Install: tzdata-legacy
    - lexicality 1y ago
      It's been backwards compatible for 30 years, you've had plenty of time to migrate
      - lmm 1y ago
        Did it give any noticeable deprecation warning? If a piece of functionality is deprecated but users can't notice, is it really deprecated?
        lexicality 1y ago
        > “Yes,” said Arthur, “yes I did. 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’.” The timezones are very clearly marked as deprecated on the lists I looked at, but on the other hand I don't live in the USA so I've never had to look particularly hard. Everything I configure is either Etc/UTC or Europe/London which is nice and easy to remember...
donalhunt 1y ago
What sort of monster are you by not defaulting to UTC on systems? (⊙＿⊙') /s
poemxo 1y ago
I don't get how this is a snag, it's right there in the log.
- skylurk 1y ago
  Agreed. > 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.
JdeBP 1y ago
This does not trace things back far enough. The root is where IANA has long since segregated out a set of timezone file names into a "backward" collection: * https://data.iana.org/time-zones/tzdb/backward 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/2008076 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 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/m/Zhx8i142qLIJ 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.
- AnssiH 1y ago
  > Launchpad marked it as "This bug affects 1 person.". That just means no one has clicked "affects me too" button yet (after logging in).
- ForHackernews 1y ago
  It's good Debian is making this change now to be prepared when the legacy United States are downed at the end of 2052.
  - tempodox 1y ago
    I can’t tell whether you’re joking. Seems like a distinct possibility now.
    - 1y ago
yellers 1y ago
Hang on a second, "(...) in 2023. US/* was moved to tzdata-legacy (...)" 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 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.
- zahlman 1y ago
  > You're telling me you didn't notice ? It was... 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).
  - rollcat 1y ago
    Then you get the reverse. I just upgraded to macOS Sonoma (yes I'm always one major version behind with Apple stuff...), and I was annoyed as heck when I had to click through "Look what's new in Calendar!", "Look what's new in Reminders!", "Look what's new in StripClubs!"... I need to use my software right now, I will not read this. Then I will forget it ever popped up, and will not read it in the future either.
    - thesuitonym 1y ago
      There's a vast difference between Apple showing you all it's useless new AI integrations and developers telling system administrators what they need to know.
      - skydhash 1y ago
        And I think Debian sent those notes also via its mail system (exim + mail). I don’t usually care for my workstation, but I do check it for my servers.
pfexec 1y ago
Debian is known to have made similar monstrously stupid decisions. For example, they patch OpenSSH source code in a way that makes defaults behave differently than upstream. In the name of backwards compatibility of course. I assume this will continue until it doesn't anymore, and the only notification you shall receive from the ivory tower is a cryptic one-liner buried in a changelog somewhere.
- burnt-resistor 1y ago
  Russ Allbery left over bureaucracy and systemd. It sounds like it's chocked full of people who want power and an excuse to patch downstream to create a cottage industry of quirks, busywork, and codependency. I prefer real choice and light patches that try to upstream as much as possible, or workaround upstream obstinacy rather than create incompatible idiosyncrasies. One area that isn't well represented in barely a/no distro is init freedom neither married to nor completely divorced from the sprawling octopus.
  - actionfromafar 1y ago
    I don't think you can be partly married to Cuthulhu. (Systemd.)
    - styanax 1y ago
      [ eldritch noises intensify ] As an actual answer, it's not too bad on Debian; we only really use/need: systemd (system and user), -logind, -journald, -udevd. All in all, not too many tentacles but there are a few...
  - joeyh 1y ago
    You are confusing Russ Allbery with me, while at the same time making it sound like I have a problem with systemd, which is not the case. Russ remains a debian developer.
    - burnt-resistor 1y ago
burnt-resistor 1y ago
Always run production systems in the Etc/UTC timezone. This eliminates an entire class of problems while only creating minor inconveniences.
- Tepix 1y ago
  For servers, i agree 100%. For desktop systems, not so much.
  - actionfromafar 1y ago
    Eastern Standard Tribe, represent!
    - kstrauser 1y ago
      I appreciated the reference.
  - kawsper 1y ago
    How else could you tell what time it is on the servers?
    - raverbashing 1y ago
      That's easy, if you're Walmart just use the TZ of your corporate HQ (That's what I heard anyway)
      - kstrauser 1y ago
        My non-Walmart startup was expanding from California to other regions many years ago, and there was some debate about whether we’d use UTC or America/Los_Angeles globally. I was part of Team Over My Dead Body.
        actionfromafar 1y ago
        But on which side? :)
Tepix 1y ago
Pro tip: Use the command timedatectl list-timezones to get a list of all timezones your debian based OS recognises. For your convenience, here is a list for a Debian 13 box with 628 entries: https://pastes.io/output-of-timedatectl-list-timezones-on-debian-13 https://pastes.io/output-of-timedatectl-list-timezones-on-de...
- guesswho_ 1y ago
  [dead]
- BrandoElFollito 1y ago
  I wonder why Poland is separate, when there is Europe/Warsaw
  - JdeBP 1y ago
    Poland is another backwards compatibility alias in the backward file; which you will notice is also in Debian's other package, as of Debian 13.
    - sevenseacat 1y ago
      As an Australian, I love that `Australia/Eucla` is there, with it's silly UTC+8.75. Some of the other Australian entries are bizarre though - 'North' and 'South'? There is no standard timezone across the whole north or south of the country. And Broken Hill is in NSW, so why are they different time zones?
roelschroeven 1y ago
> The worst part about this is that it didn't get so much as a mention in the Debian 13 release notes. I read through that document before going for it and never encountered it. Indeed, even now, you won't find "tzdata" or "zone" in it. 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.
- msk-lywenn 1y ago
  What was your issue ?
  - roelschroeven 1y ago
    The version of pdns-recursor in trixie uses a different configuration file syntax then older versions. (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.)
- styanax 1y ago
  Sharing undocumented gotcha: nginx default config (/etc/nginx/nginx.conf) now has `server_tokens off` set with a comment that it's "common practice" (agreed). This is not in upstream's git version of the file[1], I therefore presume it's a Debian maintainer change. 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://github.com/nginx/nginx/blob/master/conf/nginx.conf
  - 1y ago
acdha 1y ago
I ran into a similar bug in Git Lab where the v18 upgrade didn’t replace now-unsupported time zones so things like scheduled pipelines simply stopped running and were labeled inactive in the UI without explanation. https://gitlab.com/gitlab-org/gitlab/-/issues/556779#note_2655149512 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.
raziel2p 1y ago
> 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. You're running a database system and you just casually comment out the configuration setting the timezone? In what way did everything "seem fine"? SELECT 1 returned something? No further investigation required??
1oooqooq 1y ago
love the takes on this one blog, but "I'm copying an old conf file for over 20yrs and now got this issue" is kinda weak. American exceptionalism time zones aren't used since the 90s. even the cpus from that time are already dropped from kernel support. heck even the text encoding is gone.
- kstrauser 1y ago
  That’s unkind. I want to do the right thing in such cases, but I’m also learning about this today for the very first time. I’ve never, not once, heard that US/Pacific was a bad idea until this post. If not for this, I still wouldn’t know. I thought it and America/Los_Angeles were semantically identically and just kind of symlinks to PST8PDT or whatever. If anything, the city TZ always felt off, like I was opting in to that specific city’s strange legal decisions or something.
  - Symbiote 1y ago
    For general user interfaces, it's for the user interface to show "US Pacific" or "UK" rather than America/Los_Angeles and Europe/London. The timezone selector in KDE shows "Los Angeles | America/United States of America | Pacific" and "London | Europe/United Kingdom", for example.
  - 1oooqooq 1y ago
    > If anything, the city TZ always felt off, like I was opting in to that specific city’s strange legal decisions or something. that is exactly what time zones are for :) not being snarky (wasn't before either, i really love that blog!). but the whole reason for tz is to join the ever changing oddities of political bodies from one very specific region.
    - kstrauser 1y ago
      My point there was that it feels hyperlocal to Los Angeles. Does it have some TZ law my own city in the same zone doesn’t? Hope not! (It doesn’t, but that’s what it implies to me.)
loloquwowndueo 1y ago
Imagine my outrage when America/Montreal was deprecated years ago. “It’s the same as America/Toronto, just use that” they said :)
- ta1243 1y ago
  Have Montreal and Toronto ever been in different timezones?
  - loloquwowndueo 1y ago
    No they have not. But why not nix Toronto instead? Everybody knows Montreal is better, it should get dibs at naming the time zone. I’m just joking all the way, by the way :)
    - ta1243 1y ago
      Toronto's bigger. Same reason Boston and Washington are "New York" and Seatle/SanFrancisco are Los_Angeles (Detroit gets its own zone because it was significantly different to new york before 1970, normally it's only difference post 1970 which merit a new zone)
      - loloquwowndueo 1y ago
        Montreal is older! Montreal was there first! Montreal was once Canada’s capital! You did read the “I’m just joking” in my previous post, right? I don’t give a shit as long as I can select a city in my country and time zone :)
reactordev 1y ago
Ooofff. The two difficult things in software engineering, naming, and timestamps. This hit me in the early 2000s and now everything I do is in UTC. All dates, timestamps, everything, UTC. If you want to look at a local window in time, convert the window to a utc start and end date and search. When viewing, use a js function to translate the utc date to a local one to print. The mental gymnasium of local to utc to local again…
- dotancohen 1y ago
  > The two difficult things in software engineering, naming, and timestamps. And off-by-one errors. The two most difficult things in software engineering: naming things, timestamps, and off-by-one errors.
  - TheNewsIsHere 1y ago
    I see what you did there.
- School-Cotton 1y ago
  Some times cannot be expressed in UTC. For example: “this meeting will take place at 10 AM on July 31st, 2026, US Pacific time” cannot be expressed in UTC. You can guess what time UTC that refers to, and you’ll probably be right, but you’ll be wrong if it turns out for example that the US abolishes DST before that date.
  - zajio1am 1y ago
    In that case it is no really a time, it is a condition.
    - bmacho 1y ago
      Yup, it's a function that leads to a time, depending on some things. And you can't express it in UTC, so you better store the whole function (as a string, for example). QED
    - 1y ago
op00to 1y ago
I feel like I’ve been using America/New_York for a decade at least. Am I misremembering?
- db48x 1y ago
  No, that’s been the standard name for a quarter century.
- School-Cotton 1y ago
  That’s one of the normal Continent/City time zones, not one of the weird Country/ZoneName ones that have been deprecated for ages. “America” here refers to the continent or continents[0], not the USA. 0: Note that different cultures disagree on whether there are two continents called North America and South America, or one continent called America.
nja 1y ago
I'm still not totally sure why these names were deprecated in the first place... I mean, the folks who run the tz db definitely know what they're doing, it just never 100% clicked with my thinking. I always prefer `US/Eastern` over `America/New_York` -- it seems more "canonical" to me. New York is _currently_ the anchor city for ET, but will it always be? The place I live (Boston) is currently on ET, but in the future it might be on Atlantic Time. If there was an `America/Boston`, I would use that to be safe, but since there isn't, it just seems better to be to be specific that I mean "Eastern Time" and not "whatever the time is in NYC"... At least then if Boston switches to a different tz, I could intentionally switch to "Atlantic Time" -- doesn't that make more sense? Versus I guess what I'd have to do, which is switch to `America/Puerto_Rico`? (I had to actually search that one, too bad there's no `US/Atlantic`...)
- skydhash 1y ago
  If New-York shifts its timezone, then it will still be New-York and America. And the new tzdata will reflect that shift so your data will always be correct (as in reflecting the time it is in new york). For local time, you will switch to a new city and the date will still be correct.
  - nja 1y ago
    Exactly, but that is my point: usually my data is not intended to reflect the time it is in New York. Being tied to a (semi-)arbitrary city changes the actual meaning of the zone slightly. If every city was represented and I could choose "Boston" then that would make sense (for data is intended to reflect the time it is in Boston) but of course that's not entirely practical. (I'll note that I agree with the general wisdom to store data in UTC; here when I talk about zones I'm either talking about user local machine time or display)
- School-Cotton 1y ago
  FWIW if Boston switches, it won’t be America/Puerto_Rico, it’ll get a new zone name (probably America/Boston). Tzdb zones express that everywhere in that zone has always been on the same time, since the advent of standard timekeeping, so they always fracture when some subset moves to a different zone.
liampulles 1y ago
tz-announce is a nice mailing list to subscribe to, useful info and fascinating. https://lists.iana.org/hyperkitty/list/tz-announce@iana.org/latest https://lists.iana.org/hyperkitty/list/tz-announce@iana.org/...
nona 1y ago
This is why Debian users should use apt-listchanges to display the latest NEWS.Debian items on upgrade. 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.
- TheNewsIsHere 1y ago
  You’re not wrong in general terms, but tzdata is fairly well essential, a default component, and a dependency for unpteen things in the ecosystem. Of course a line must be drawn somewhere, but this really is a “major” caveat.

284 points by move-on-by 1y ago

ggm 1y ago

Is there a problem with ISO3166 denoted information in general or is there a specific US issue here? I would think ISO code denoted tzdata was a public good in some sense.

evdubs 1y ago
You can see the zones that are deprecated at https://packages.debian.org/sid/all/tzdata-legacy/filelist https://packages.debian.org/sid/all/tzdata-legacy/filelist
masklinn 1y ago
All the legacy time zones were moved out of the default zoneinfo install. It’s not a us-specific issue but the legacy US/ timezones remain in widespread use, and they stop working on Debian 13 ootb (possibly Ubuntu noble as well?).
- pdw 1y ago
  Are they in widespread use? They were deprecated in 1995.
  - ahoef 1y ago
    I don't see conflict in those statements.
- pixelesque 1y ago
  Does anyone know why they are still in widespread use? Config defaults somewhere still using them? Man page examples? Tutorials using them? Or just force of habit?
  - rtpg 1y ago
    Some of this is surely just muscle memory or intertia as well. I remember random config values from when I was trying out linux boxes back in high school that I replicated into files that just don't get touched for decades afterwards. When was the last time you rebuilt your company's postgres config from scratch?
    - Symbiote 1y ago
      > When was the last time you rebuilt your company's postgres config from scratch? Last year, when we upgrade to version 17. I looked at the example/template configuration, diffed it with our configuration from PG15, and for every change decided whether to keep our version or the new setting. I didn't use it, but Debian/APT has had a tool to do this sort of comparison for any software upgrade for as long as I can remember. Do other people just copy the old config and shout "YOLO!"?
      - rtpg 1y ago
        When your configuration value from PG15 was different from the old default and the new default on something like the statement timeout, and the statement timeout was previously working fine, and obstensibly set for a reason.... I dunno, are you going to question the value that much? And you might say "well I know how a statement timeout works" and I agree! I would also generally agree that something like a timezone setting would generally be something I'd expect to be fairly stable. That's what I meant about rebuilding the config from scratch. Rebuilding from scratch would almost involve _not even looking at the existing configuration_ and then doing first principles footwork to figure out what is needed. I think the diffing flow you went through is the right way to do it, but I believe that flow might lead to some values getting less scrutiny than others. Still perfectly reasonable though
    - magicalhippo 1y ago
      Still typing "nano -w filename" each and every time since back around y2k when I was working on Linux for the first time I was told that bad things could happen if I didn't...
mananaysiempre 1y ago
This has nothing to do with ISO 3166 at all. The tzdata database is the work of a single person, Arthur Olson, not a committee (or rather it was, from its birth in the 1980s until 2011 when a company decided to sue him for no reason). And for most of its life it’s been an explicit policy that timezones are named by continent and representative population center, not by country, to avoid entangling it in territorial disputes and improve naming stability for historical data. The US/* (and Canada/*, etc.) names are deprecated and have been since 1995 (?), but apparently people were still using them because the deprecation wasn’t really apparent unless one was especially into reading release notes.
- breakingcups 1y ago
  Interesting, I hadn't heard about that frivolous lawsuit before: https://www.eff.org/press/releases/eff-wins-protection-time-zone-database https://www.eff.org/press/releases/eff-wins-protection-time-...

evdubs 1y ago

I also ran into this using: - 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`.

raverbashing 1y ago

[flagged]

rlpb 1y ago
The timezone names are defined by the Olson database, not Debian. It is the only sensible system in our ecosystem. It certainly beats Outlook which still wrongly insists that my timezone is GMT just because I live in the UK and still confuses everyone (it isn't during the summer; we use BST over the summer, not GMT).
- raverbashing 1y ago
  Any moderately reasonable system would be backwards compatible and/or migrate existing values > The worst part about this is that it didn't get so much as a mention in the Debian 13 release notes. I read through that document before going for it and never encountered it. Indeed, even now, you won't find "tzdata" or "zone" in it.
  - ars 1y ago
    > Any moderately reasonable system would be backwards compatible It is. Install: tzdata-legacy
  - lexicality 1y ago
    It's been backwards compatible for 30 years, you've had plenty of time to migrate
    - lmm 1y ago
      Did it give any noticeable deprecation warning? If a piece of functionality is deprecated but users can't notice, is it really deprecated?
      - lexicality 1y ago
        > “Yes,” said Arthur, “yes I did. 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’.” The timezones are very clearly marked as deprecated on the lists I looked at, but on the other hand I don't live in the USA so I've never had to look particularly hard. Everything I configure is either Etc/UTC or Europe/London which is nice and easy to remember...

donalhunt 1y ago

What sort of monster are you by not defaulting to UTC on systems? (⊙＿⊙') /s

poemxo 1y ago

I don't get how this is a snag, it's right there in the log.

skylurk 1y ago
Agreed. > 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.

JdeBP 1y ago

This does not trace things back far enough. The root is where IANA has long since segregated out a set of timezone file names into a "backward" collection: * https://data.iana.org/time-zones/tzdb/backward 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/2008076 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 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/m/Zhx8i142qLIJ 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.

AnssiH 1y ago
> Launchpad marked it as "This bug affects 1 person.". That just means no one has clicked "affects me too" button yet (after logging in).
ForHackernews 1y ago
It's good Debian is making this change now to be prepared when the legacy United States are downed at the end of 2052.
- tempodox 1y ago
  I can’t tell whether you’re joking. Seems like a distinct possibility now.
  - 1y ago

yellers 1y ago

Hang on a second, "(...) in 2023. US/* was moved to tzdata-legacy (...)" 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 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.

zahlman 1y ago
> You're telling me you didn't notice ? It was... 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).
- rollcat 1y ago
  Then you get the reverse. I just upgraded to macOS Sonoma (yes I'm always one major version behind with Apple stuff...), and I was annoyed as heck when I had to click through "Look what's new in Calendar!", "Look what's new in Reminders!", "Look what's new in StripClubs!"... I need to use my software right now, I will not read this. Then I will forget it ever popped up, and will not read it in the future either.
  - thesuitonym 1y ago
    There's a vast difference between Apple showing you all it's useless new AI integrations and developers telling system administrators what they need to know.
    - skydhash 1y ago
      And I think Debian sent those notes also via its mail system (exim + mail). I don’t usually care for my workstation, but I do check it for my servers.

pfexec 1y ago

Debian is known to have made similar monstrously stupid decisions. For example, they patch OpenSSH source code in a way that makes defaults behave differently than upstream. In the name of backwards compatibility of course. I assume this will continue until it doesn't anymore, and the only notification you shall receive from the ivory tower is a cryptic one-liner buried in a changelog somewhere.

burnt-resistor 1y ago
Russ Allbery left over bureaucracy and systemd. It sounds like it's chocked full of people who want power and an excuse to patch downstream to create a cottage industry of quirks, busywork, and codependency. I prefer real choice and light patches that try to upstream as much as possible, or workaround upstream obstinacy rather than create incompatible idiosyncrasies. One area that isn't well represented in barely a/no distro is init freedom neither married to nor completely divorced from the sprawling octopus.
- actionfromafar 1y ago
  I don't think you can be partly married to Cuthulhu. (Systemd.)
  - styanax 1y ago
    [ eldritch noises intensify ] As an actual answer, it's not too bad on Debian; we only really use/need: systemd (system and user), -logind, -journald, -udevd. All in all, not too many tentacles but there are a few...
- joeyh 1y ago
  You are confusing Russ Allbery with me, while at the same time making it sound like I have a problem with systemd, which is not the case. Russ remains a debian developer.
  - burnt-resistor 1y ago

burnt-resistor 1y ago

Always run production systems in the Etc/UTC timezone. This eliminates an entire class of problems while only creating minor inconveniences.

Tepix 1y ago
For servers, i agree 100%. For desktop systems, not so much.
- actionfromafar 1y ago
  Eastern Standard Tribe, represent!
  - kstrauser 1y ago
    I appreciated the reference.
- kawsper 1y ago
  How else could you tell what time it is on the servers?
  - raverbashing 1y ago
    That's easy, if you're Walmart just use the TZ of your corporate HQ (That's what I heard anyway)
    - kstrauser 1y ago
      My non-Walmart startup was expanding from California to other regions many years ago, and there was some debate about whether we’d use UTC or America/Los_Angeles globally. I was part of Team Over My Dead Body.
      - actionfromafar 1y ago
        But on which side? :)

Tepix 1y ago

Pro tip: Use the command timedatectl list-timezones to get a list of all timezones your debian based OS recognises. For your convenience, here is a list for a Debian 13 box with 628 entries: https://pastes.io/output-of-timedatectl-list-timezones-on-debian-13 https://pastes.io/output-of-timedatectl-list-timezones-on-de...

guesswho_ 1y ago
[dead]
BrandoElFollito 1y ago
I wonder why Poland is separate, when there is Europe/Warsaw
- JdeBP 1y ago
  Poland is another backwards compatibility alias in the backward file; which you will notice is also in Debian's other package, as of Debian 13.
  - sevenseacat 1y ago
    As an Australian, I love that `Australia/Eucla` is there, with it's silly UTC+8.75. Some of the other Australian entries are bizarre though - 'North' and 'South'? There is no standard timezone across the whole north or south of the country. And Broken Hill is in NSW, so why are they different time zones?

roelschroeven 1y ago

> The worst part about this is that it didn't get so much as a mention in the Debian 13 release notes. I read through that document before going for it and never encountered it. Indeed, even now, you won't find "tzdata" or "zone" in it. 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.

msk-lywenn 1y ago
What was your issue ?
- roelschroeven 1y ago
  The version of pdns-recursor in trixie uses a different configuration file syntax then older versions. (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.)
styanax 1y ago
Sharing undocumented gotcha: nginx default config (/etc/nginx/nginx.conf) now has `server_tokens off` set with a comment that it's "common practice" (agreed). This is not in upstream's git version of the file[1], I therefore presume it's a Debian maintainer change. 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://github.com/nginx/nginx/blob/master/conf/nginx.conf
- 1y ago

acdha 1y ago

I ran into a similar bug in Git Lab where the v18 upgrade didn’t replace now-unsupported time zones so things like scheduled pipelines simply stopped running and were labeled inactive in the UI without explanation. https://gitlab.com/gitlab-org/gitlab/-/issues/556779#note_2655149512 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.

raziel2p 1y ago

> 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. You're running a database system and you just casually comment out the configuration setting the timezone? In what way did everything "seem fine"? SELECT 1 returned something? No further investigation required??

1oooqooq 1y ago

love the takes on this one blog, but "I'm copying an old conf file for over 20yrs and now got this issue" is kinda weak. American exceptionalism time zones aren't used since the 90s. even the cpus from that time are already dropped from kernel support. heck even the text encoding is gone.

kstrauser 1y ago
That’s unkind. I want to do the right thing in such cases, but I’m also learning about this today for the very first time. I’ve never, not once, heard that US/Pacific was a bad idea until this post. If not for this, I still wouldn’t know. I thought it and America/Los_Angeles were semantically identically and just kind of symlinks to PST8PDT or whatever. If anything, the city TZ always felt off, like I was opting in to that specific city’s strange legal decisions or something.
- Symbiote 1y ago
  For general user interfaces, it's for the user interface to show "US Pacific" or "UK" rather than America/Los_Angeles and Europe/London. The timezone selector in KDE shows "Los Angeles | America/United States of America | Pacific" and "London | Europe/United Kingdom", for example.
- 1oooqooq 1y ago
  > If anything, the city TZ always felt off, like I was opting in to that specific city’s strange legal decisions or something. that is exactly what time zones are for :) not being snarky (wasn't before either, i really love that blog!). but the whole reason for tz is to join the ever changing oddities of political bodies from one very specific region.
  - kstrauser 1y ago
    My point there was that it feels hyperlocal to Los Angeles. Does it have some TZ law my own city in the same zone doesn’t? Hope not! (It doesn’t, but that’s what it implies to me.)

loloquwowndueo 1y ago

Imagine my outrage when America/Montreal was deprecated years ago. “It’s the same as America/Toronto, just use that” they said :)

ta1243 1y ago
Have Montreal and Toronto ever been in different timezones?
- loloquwowndueo 1y ago
  No they have not. But why not nix Toronto instead? Everybody knows Montreal is better, it should get dibs at naming the time zone. I’m just joking all the way, by the way :)
  - ta1243 1y ago
    Toronto's bigger. Same reason Boston and Washington are "New York" and Seatle/SanFrancisco are Los_Angeles (Detroit gets its own zone because it was significantly different to new york before 1970, normally it's only difference post 1970 which merit a new zone)
    - loloquwowndueo 1y ago
      Montreal is older! Montreal was there first! Montreal was once Canada’s capital! You did read the “I’m just joking” in my previous post, right? I don’t give a shit as long as I can select a city in my country and time zone :)

reactordev 1y ago

Ooofff. The two difficult things in software engineering, naming, and timestamps. This hit me in the early 2000s and now everything I do is in UTC. All dates, timestamps, everything, UTC. If you want to look at a local window in time, convert the window to a utc start and end date and search. When viewing, use a js function to translate the utc date to a local one to print. The mental gymnasium of local to utc to local again…

dotancohen 1y ago
> The two difficult things in software engineering, naming, and timestamps. And off-by-one errors. The two most difficult things in software engineering: naming things, timestamps, and off-by-one errors.
- TheNewsIsHere 1y ago
  I see what you did there.
School-Cotton 1y ago
Some times cannot be expressed in UTC. For example: “this meeting will take place at 10 AM on July 31st, 2026, US Pacific time” cannot be expressed in UTC. You can guess what time UTC that refers to, and you’ll probably be right, but you’ll be wrong if it turns out for example that the US abolishes DST before that date.
- zajio1am 1y ago
  In that case it is no really a time, it is a condition.
  - bmacho 1y ago
    Yup, it's a function that leads to a time, depending on some things. And you can't express it in UTC, so you better store the whole function (as a string, for example). QED
  - 1y ago

op00to 1y ago

I feel like I’ve been using America/New_York for a decade at least. Am I misremembering?

db48x 1y ago
No, that’s been the standard name for a quarter century.
School-Cotton 1y ago
That’s one of the normal Continent/City time zones, not one of the weird Country/ZoneName ones that have been deprecated for ages. “America” here refers to the continent or continents[0], not the USA. 0: Note that different cultures disagree on whether there are two continents called North America and South America, or one continent called America.

nja 1y ago

I'm still not totally sure why these names were deprecated in the first place... I mean, the folks who run the tz db definitely know what they're doing, it just never 100% clicked with my thinking. I always prefer `US/Eastern` over `America/New_York` -- it seems more "canonical" to me. New York is _currently_ the anchor city for ET, but will it always be? The place I live (Boston) is currently on ET, but in the future it might be on Atlantic Time. If there was an `America/Boston`, I would use that to be safe, but since there isn't, it just seems better to be to be specific that I mean "Eastern Time" and not "whatever the time is in NYC"... At least then if Boston switches to a different tz, I could intentionally switch to "Atlantic Time" -- doesn't that make more sense? Versus I guess what I'd have to do, which is switch to `America/Puerto_Rico`? (I had to actually search that one, too bad there's no `US/Atlantic`...)

skydhash 1y ago
If New-York shifts its timezone, then it will still be New-York and America. And the new tzdata will reflect that shift so your data will always be correct (as in reflecting the time it is in new york). For local time, you will switch to a new city and the date will still be correct.
- nja 1y ago
  Exactly, but that is my point: usually my data is not intended to reflect the time it is in New York. Being tied to a (semi-)arbitrary city changes the actual meaning of the zone slightly. If every city was represented and I could choose "Boston" then that would make sense (for data is intended to reflect the time it is in Boston) but of course that's not entirely practical. (I'll note that I agree with the general wisdom to store data in UTC; here when I talk about zones I'm either talking about user local machine time or display)
School-Cotton 1y ago
FWIW if Boston switches, it won’t be America/Puerto_Rico, it’ll get a new zone name (probably America/Boston). Tzdb zones express that everywhere in that zone has always been on the same time, since the advent of standard timekeeping, so they always fracture when some subset moves to a different zone.

liampulles 1y ago

tz-announce is a nice mailing list to subscribe to, useful info and fascinating. https://lists.iana.org/hyperkitty/list/tz-announce@iana.org/latest https://lists.iana.org/hyperkitty/list/tz-announce@iana.org/...

nona 1y ago

This is why Debian users should use apt-listchanges to display the latest NEWS.Debian items on upgrade. 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.

TheNewsIsHere 1y ago
You’re not wrong in general terms, but tzdata is fairly well essential, a default component, and a dependency for unpteen things in the ecosystem. Of course a line must be drawn somewhere, but this really is a “major” caveat.