Posted by move-on-by 1 day ago
https://lists.iana.org/hyperkitty/list/tz-announce@iana.org/...
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…
> The two difficult things in software engineering, naming, and timestamps.
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.
Moreover, most people in real life will understand that to be a time and won’t care how it maps to UTC.
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`...)
It's one guy. He demonstrably does NOT know what he's doing.
> I always prefer `US/Eastern`
As you should. It's the actual name of the timezone as published by the entity that defines it. Outside of the goofy definitions in the tz file it's what everyone living _inside_ of that timezone would call it and see it referenced as.
To call this "backwards" is an absolute insult to civil time keeping and drives me insane.
> doesn't that make more sense?
I always thought it should be served through DNS. Then each country can just define it's own TZ record type and embed it at the root of their country code domain and could expand on it however they like.
eastern.timezone.us
Also, since domain names have punycode for internationalization, you could actually call timezones in countries like Mexico what they're actually named for end users.
You could use this to promulgate SRV records that direct you to a country’s authoritative time servers, too.
(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)
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??
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.
Config defaults somewhere still using them? Man page examples? Tutorials using them? Or just force of habit?
Because of a lack of things compelling people to change them until it causes a breakage. And then when it does cause a breakage, most people would rather move heaven and earth to complain, research workarounds, etc. rather than just change it. (Institutional structures can also make "just" changing it far harder than that should be.)
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!"?
Given the old names were deprecated in 1993, it's hardly surprising that I never before discovered "GB".
I’m just joking all the way, by the way :)
(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)
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 :)
I went to both Outlook and Teams to check and I have the option to select both "(UTC) Universal Coordinated Time" and "(UTC+0) Dublin, Edinburgh, Lisbon, London", with the later adapting to changes in the summer; but I do agree it's clunkier than the Olson database, combining multiple regions in a single option while splitting regions with the same timezone rules into different ones.
This is factually wrong already. In summer, London is not UTC+0. They mean "UTC+0 ignoring DST", but that is not useful. If they're going to be specific by specifying a UTC offset, what's the point if it doesn't include DST? How is that useful as an identifier when it's ambiguous? With their history of getting it wrong, this just introduces doubt about its correctness.
Further, if you ask Outlook to show you two timezones at once and do not override labels, it will label BST "UTC+0" (it isn't; it's UTC+1!) while also calling eg. India "UTC+5:30", implying a time difference of 5.5 hours when it is actually 4.5 hours. This isn't just a case of "ah - they actually mean ..."; it's most definitely wrong!
The problem is that it has a very US-centric view of what DST is. You can mostly ignore it in the US when calculating time zones because the entire country changes DST at the same time. This is not the case internationally.
Yeah, the "regular" time is UTC+0, with it changing in the summer. I'm aware it's a really poor implementation, but it is there as a separate option from "UTC" itself preserving the same offset (0) all year.
> The problem is that it has a very US-centric view of what DST is. You can mostly ignore it in the US when calculating time zones because the entire country changes DST at the same time. This is not the case internationally.
Probably the reason they, for some reason, split the setting for "Amsterdam, Bern, Berlin, Rome, Stockholm, Vienna" and "Brussels, Copenhaguen, Madrid, Paris" even though they all follow the same timezone and change simultaneously.
This is how 99% of people interpret it
It's not ambiguous as you imply.
Summer time is not the default time
I don't know enough about the India case to know how/why it's wrong though
Your TZ doesn't change between summer and winter. What changes is the shift
I literally didn't see anybody getting confused with this in any country (yes, including Ireland) with summer time.
But some people think they're too smart when they nitpick about minor issues
My TZ is GMT in winter and BST in summer. I am not in GMT in summer. GMT continues to exist in summer, doesn't shift but my clock doesn't follow it.
The UTC "shift" changes indeed. When I am DST-shifted, calling me "UTC" is absolutely wrong.
The practical issue is that people still use "UTC" and "GMT" interchangeably, which is roughly correct anyway since they remain the same in practice. But then during summer when someone says GMT I don't know if they actually mean BST (they mean my local time) or UTC (they mean the global point of reference). That ambiguity only arises because Outlook (and you, apparently) conflate GMT and BST. It's far more of a problem for those actually living in a UTC-adjacent time zone (do you?), especially because being only one hour off, usually both options seem equally likely in context.
> 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.
System logs?
> It's not as if C APIs get designed up front to return structures with a boolean "btw you called this in a nonstandard way that might fuck up in the future" flag (or, say, a pointer to a deprecation-warning structure; and then that interface has to be rock-solid stable to be of use) for every call. And if they did, nobody would ever write code that checks it.
Yeah, fair point, no-one should be using a C API at this point.
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...
It is. Install: tzdata-legacy
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.
If anything, the city TZ always felt off, like I was opting in to that specific city’s strange legal decisions or something.
The timezone selector in KDE shows "Los Angeles | America/United States of America | Pacific" and "London | Europe/United Kingdom", for example.
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.
(It doesn’t, but that’s what it implies to me.)
One important thing to understand is that the time zones of the tz database, and hence generally the time zones used in computing, are a slightly different concept than legislative time zones.
Still feels weird, though. What if LA specifically passes a time zone law so that now it’s sometimes wrong for everyone else in California. Do we add an America/Cali_except_LA zone?
That’s probably hypothetical. It seems unlikely. But what a major pain in the ass if it did happen?
So the trade-off is timezones being specific to a particular city but remaining unambiguous forward and backward in time.
You can’t avoid pain when there is a change in the geographic area of a legislative time zone. But you can avoid the case of a time zone ID becoming ambiguous in terms of the UTC<—>local time mapping it’s supposed to define. The latter is the aim of the present scheme.
Yes, it's silly and inefficient, but so are time zones. It's not an easy problem to wrangle on a computer, for reasons that are exactly as you have described.
It’s an inherently complex, ugly mess.
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.
Isn't it the same thing with the RedHat downstreams ? (Not necessarily OpenSSH but other packages)
IIRC RedHat do all sorts of things to keep their gov / corp customers happy, also usually in the name of backwards compatability, all of which then end up in the downstreams.
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.
Also, I worked in the same department as Russ once upon a time in a galaxy far, far away.
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...