That's the problem with writing posts both of the "everyone else is doing things WRONG, those dang fools" (e.g. the series on RSS readers) and "oops, I did a stupid mistake, heh, TIL" styles and variety: the latter ones tend to attract comments from "The One" (oh noes) referencing the first kind of posts. Naturally, a humble person would simply read them, note them, and move on withouth replying — but a humble would person would not write the "everyone else is doing things WRONG, those dang fools" kind of posts either in the first place; and so we get the third kind of posts, the ones with "yeah, I did a small mistake, but I've admitted it myself, so no one else is allowed to criticize me; anyway..." disclaimer on the top.
P.S. I do distictly remember how a reply on HN to one of her earlier posts on RSS clients mentioned that her laments kinda miguided since her own feed doesn't set one very well-documented and basic cache-controlling HTTP header that most readers actually do respect; but some time later in her later post she described that header as matter-of-fact knowlewdge, no "I've learned about this one recently" remark or anything, and by that time, her RSS feed had started setting it.
I don't know, with her RSS saga, she actually provided a tool to test one's RSS feed reader and helped find bugs and this lead to fixes in many RSS tools, making things better for everyone. She put in the work. I find the approach quite constructive.
Well, yes, it did improve that particular area of software. Although for about 15 years that wasn't really problem for anyone who didn't self-host their blog on a potato attached to the Internet with a phone coupler and copper-wires; you can find comments at HN in the relevant discussions from the people who apparently serve about the same amount amount of (almost) static traffic she complains about while it costs them like $2 monthly or something. Now AI crawlers, those are quite a problem...
While I am personally glad that now there are less infuriatingly stupid network clients around (although, again, those never really amounted to all that much load), and probably adopting a rather caustic attitude at the authors of RSS clients was the only to force them to fix things, but even then: you can do more with a kind word and a gun than with just a gun. Besides, there is some unspoken etiquette between the content servers and content readers; a server that e.g. bans you for exceeding rate-limits when you open the "Full blog archives" page and middle-click at 10 promisingly named links to read them one after another is just rude, personal opinions of the hoster notwithstanding.
P.S. Seriously, max-age=155520? Your server/ISP can't handle serving a ~190 KiB (when gzipped) file even once a day, it has to be almost 2 days? Get it off the public Internet then.
(I should note that in my crowd, references to this movie are always super-negative. "The One" gets damned to hell to eternally fight, but never win his battle.)
I'm not sure I understand the purpose of these blog posts for what is, at best, a simple bug in Debian. When I encounter something like this, I find steps to reproduce and file a bug. That's it.
If someone wants to get indignant and broadcast how terrible it is that a project (Debian in this case) is so terrible that they dare have a UX issue that is probably just an oversight, then they're entitled to do that but can also expect pushback where they aren't perfect either.
The core issue is that tzdata files do not contain the time zone identifier. If you are unlucky in /etc/localtime is not a symbolic link, you have to scan the files in /usr/share/zoneinfo to find a match. PostgreSQL prefers shorter names: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit...
Looking at that code I’m shocked that Postgres allows two-liner if statements without a matching {} (I’m sure someone pedantically will point out that I’m using the wrong terminology or that it was actually several lines of conditionals).
This practice is very bug prone, and has lead to high profile failures like goto fail
The project history goes back to 1982. There may have been rewrites in the later 80s, but it's some of the oldest C around, and a very conservative codebase (e.g. Linux kernel gets much more aggressive refactorings regularly).
These days people might not blink an eye at gofmt/rustfmt rewriting the AST to clean it up, but those toolchains were built that way largley because automating anything about large C codebases is so hard.
Large stable projects are very much wary of wide-scale changes their codebase. What they have is tested working by decades in production. Especially with C where tooling is brittle.
Let me put this way: If you submit a code prettifying patch to the Linux kernel, it will not be accepted. The risks aren't worth it.
The only real way forward is full migration away from C, for which a better scope is a separate project.
These days, there are compiler diagnostics for that. There's also a pgindent tool, which will align the visual presentation of the code with its syntactic structure.
Are you saying they should always be present? Or only when the condition takes multiple lines; i.e. do you take issue with the ifs in zone_name_pref too?
Personally I think the indentation does a good enough job here.
It's worth noting that a new installation of Debian will still display the same Eastern, Central, Mountain, Pacific menu to the user as shown in the screenshot. It just maps those to the non-deprecated names now.
Read the previous blog post [0] -- this one is disjointed without it. I dislike TZ selectors that use locations (cities, countries, etc.). Let PDT be PDT(-8) and PST be PST(-7). Why do I need to choose Cupertino, CA (or LA in the blog post example) -- locations over 1k miles away from me? And while I certainly understand where Cupertino is and how it relates to my TZ, what if someone else doesn't? Cupertino isn't a major population center.
Anyway, poor UX. But of course TZ names could also be argued as poor UX. What if you just did PST/PDT as Los Angeles, CA; Oregon, OR, and Seattle, WA all on separate line items? Sure, it's duplicate data but a backend system (Postgres config files, say) should only store the value of the TZ, i.e. -7 / -8. At least a user could recognize 'oh, I drive to xyz major city occasionally, that's the choice I want'.
To keep ranting, I checked macOS 15 TZ selector for PDT/PST. The selector itself is labeled "Closest city". It has numerous locations in California, a few in Nevada, and a couple in Mexico. No cities in Oregon, Washington, or Idaho (and Hyder, AK... neat [1]).
Closest is a stretch, like I said, over 1K miles from LA. But why several California cities, including minor ones like Oceanside (~175K people), but nothing in Oregon (Eugene, also 175K), Portland (652K), or Washington - Tacoma (220K), Seattle (740K). Note I did not look for the smallest city in the macOS CA list.
It's weird to me. Maybe it's because Oregon == Intel and Washington == Microsoft. ;-)
> Anyway, poor UX. But of course TZ names could also be argued as poor UX. What if you just did PST/PDT as Los Angeles, CA; Oregon, OR, and Seattle, WA all on separate line items? Sure, it's duplicate data but a backend system (Postgres config files, say) should only store the value of the TZ, i.e. -7 / -8.
Because that doesn't tell you when the timezone changes. Two locales can share timezones but start or end daylight savings time at different times.
For instance, Cuba and Florida are both -4 / -5, but Cuba starts and ends daylight savings time 2 hours and 1 hour, respectively, before Florida.
Then there's the fact that locales, once in a while, will change what timezone they're in (like Samoa in 2011) or stop/start observing daylight savings time. Having the timezone set to a place largely solves this problem.
Maybe it could be a forcing function for the less-majority DST-rule countries to align to the majority, once they figure out that their IT systems have trouble twice a year they'll be sure to vote on it.
> Let PDT be PDT(-8) and PST be PST(-7). Why do I need to choose Cupertino, CA (or LA in the blog post example)
Whether daylight savings time is being used at a given location at a given time of year is a matter of government policy. The city-based timezone selectors should handle that automatically based on the jurisdiction you choose.
> Sure, it's duplicate data but a backend system (Postgres config files, say) should only store the value of the TZ, i.e. -7 / -8.
Then the time may be wrong for half the year depending on where you are.
There's no America/Salt_Lake_City you're recommended to use America/Boise instead. The people in Salt Lake City are about as far away from Boise as you can get and Salt Lake City is more easily recognized as a landmark then Boise. The process of choosing which cities should be landmark cities comes across as faulty and uninformed.
The reason why certain cities get entries is because sometime after time began (1970-01-01), the region they're in changed their timezone (usually adopting or dropping DST or changing when it began). Those changes need to be recorded in the timezone database. The largest city in the affected area is typically chosen to be representative of the area.
Boise has its own entry because in 1974, the Emergency Daylight Time Act shifted when DST began in Southern Idaho and eastern Oregon. Boise is the largest city in the region.
Technically, if you're in Salt Lake City, you should be using America/Denver, not Boise because of this, otherwise if you say, opened a calendar from 1974, everything will be off by an hour.
If Utah made DST there begin a day earlier this year, Salt Lake City would probably get an entry too.
I think for the US, they should ensure tzdata contains at least one city for every state. That’s what they do for Australia. Now, it so happens their current rules-only add city if in recent decades it had distinct time zone rules-happen to produce that outcome for Australia, because in Australia time is a state issue and historically every state decided for itself whether to have daylight savings and when to begin/end it. Still, I think they should amend their rules to say “capital and/or largest city for every first-level subdivision of major countries”, given some reasonably objective definition of “major” (e.g. G20 nations)
The problem in the US is that time zone boundaries very frequently do not match state boundaries.
It’s common for major cities to be located on rivers that are state boundaries, the area around the city uses the same timezone, and one of the states has a timezone boundary in the middle. Indiana has many tz database entries because of this kind of thing.
There are other fun cases like the Navajo Nation in Arizona.
I live in South Dakota, which is one of them—the Mountain/Central timezone boundary within the state follows the Missouri river. (Locals refer to "East River" and "West River" to refer to the two halves of the state. The capital, Pierre, is technically East River, but is right on the banks, almost dead-center.)
Australia has an entry for a major city per state not because someone decided it was a good idea, but for the same reason Boise got one - they were the largest city in a jurisdiction that sometime after 1970 changed its timezone so it didn't match anyone else which necessitated adding an entry in order to record the unique timezone rules for them.
For instance, both Sydney and Melbourne both have entries because Victoria and New South Wales have started/ended daylight savings time in various years since 1970 on different dates like in 1990 when in Victoria it ended on March 18 while in New South Wales it ended on March 4.
It's also why Broken Hill has an entry despite being in New South Wales, they're in their own timezone.
There's a tradeoff between subdivisions per country and the UX that causes for timezine picker dropdowns in making everyone else scroll past all the US, Canada, India etc. subdivisions
> Those changes need to be recorded in the timezone database.
The issue with this thinking is that all existing datimes referring to that region will continue using the old timezone because the new one didn't exist yet.
Salt Lake City is a 4.5-5 hour drive from Boise. If you want a better example, there are no cities in Texas in the list, and Chicago is a lot further away than Boise is from Salt Lake City!
> The process of choosing which cities should be landmark cities comes across as faulty and uninformed.
I think it's unlikely they're chosen as landmark cities. More likely, timezones were uniform, then some government likely did their own thing in their jurisdiction. The change was then represented as a new timezone named after the place where the change is centered. IOW, the names have more to do with some random divergence that happened at some point in history, rather than what landmarks are the most recognized for today's timezones. Re: Boise & Salt Lake City, maybe Boise was the first to do their own thing while Salt Lake City had a different timezone. Maybe Salt Lake City later decided to adjust their timezone to fit Boise's to facilitate commerce between their states.
You can't just go by time zone names because there are weird exceptions, like most of Arizona not doing DST. Then there's Indiana, which didn't do DST until 20 years ago, and there are some counties that switched time zones when the DST law took effect... if you're in one of those counties will you just accept old timestamps being an hour off? Granted, this gradually becomes less of an issue the further we get from the change. But nothing guarantees that there won't be further changes in the future.
And that's just the US, there's almost 200 other countries each with their own laws.
> But nothing guarantees that there won't be further changes in the future.
There are guarantees that there will be changes in the future! There are changes regularly, some expected, some not. In some countries the suspension of DST due to Ramadan is decided on the first night of Ramadan itself when a group of elders look at the moon and decide whether Ramadan starts tonight, or tomorrow.
Even abbreviations have issues. PST (UTC+8) is also Philippine Standard Time. EST could mean Eastern Standard Time in Australia, granted that nowadays is AEST.
Timezones are such a headache. Obviously even UTC for a location varies depending on the time of year.
Even the International Space Station shifted timezones from Houston time to UTC+0.
Curiosity and Perseverance's clocks are UTC but operations run on LMST (local mean solar time) Gale Crater and LMST Jezero Crater- their landing locations. That point is moot until humans start spinning up VMs on Mars which they will one day.
> Obviously even UTC for a location varies depending on the time of year.
The offset from UTC for a location varies depending on time of year but UTC definitionally has a zero offset throughout the year.
If you’re in the Europe/London time zone your time is equal to GMT/UTC (offset zero) for half the year and BST (offset +1) for the other half.
In other words we have two different types here: Timezones based on location where the UTC offset varies, and the UTC offset itself (like +0100/BST or +0000/GMT/Z.)
I remember getting yelled at by an American on Reddit once, when I asked what they meant by EST. Because of course America is the only country that shouldn't have to use country-prefixed versions of anything.
And of course, saying 'EST' doesn't actually tell me what fucking time something is happening. Telling me what UTC offset EST is, does.
> Anyway, poor UX. But of course TZ names could also be argued as poor UX. What if you just did PST/PDT as Los Angeles, CA; Oregon, OR, and Seattle, WA all on separate line items?
If your application can access the current location you don't need to expose a TZ selector to the user. You can figure out what time zone database sector you're in automatically.
> Sure, it's duplicate data but a backend system (Postgres config files, say) should only store the value of the TZ, i.e. -7 / -8.
Your backend needs to store location because places can switch time zones. The reason for the seemingly arbitrary list of cities is they each define a region where clocks have been synchronized since 1970.
I’m not letting applications access my location just to let it pick a time zone.
IP geolocation is often wrong and inaccurate. I’ve had a VPS whose IP was geolocated 360 km away, in another country and time zone. But even with residential IPs, they might be pointing to a different time zone in countries with multiple zones.
> Your backend needs to store location because places can switch time zones.
For the event, your backend only needs to store the timestamp in a timestamptz field and make sure that clients set the correct time zone on session start (this you might want the backend to store in the database too, but probably in the users table).
A bit of an edge case, but there's also the problem that the time zone you pick today might not be the time zone you have tomorrow: The jurisdiction you're in can change what their clocks use on an institutional whim.
It's very unlikely, but tomorrow some state or major city in PST could decide to add 15 minutes to all their wall clocks. Should your computer's clock change? That depends on what you're using it for...
The problem is both the US and Australia have “EST/EDT” - the Australian version sometimes has an A stuck on the front to disambiguate it from the US timezone, but that isn’t always done (especially given some systems insist timezone abbreviations can be max 3 characters). And the problem with disambiguating on the basis of UTC offsets is you’d be surprised by how many people have no clue what any of them are. But “Americas” vs “Australia”, they’ll get that right
I suspect a large number of users might choose PST if in California, when they really mean PST/PDT. Or perhaps in the summer they would semi-correctly choose PDT.
Choosing a large city you know shares your time zone does make things a bit more “human“.
I’m currently working at one of the world’s largest consumer banks, and for a company that really should care about the accuracy of such things, I see “EST’ frequently all summer long.
True; I should have said "most people refer to their local timezone in that way". (The reason I didn't was because at the time, I was referring to those specific timezones, not because I was picking on Americans.)
> I dislike TZ selectors that use locations (cities, countries, etc.). Let PDT be PDT(-8) and PST be PST(-7).
You can choose that. Set your timezone to Etc/GMT-8. Then, at the exact time your political jurisdiction mandates switching over to PST, go to all your computers and switch them all to Etc/GMT-7. Then do the same thing next year for switching back.
What? That's bad UX as well? Well then, you have to name the correct political jurisdiction that mandates the timezone rules where you live. And that's hard, because so many little tinkerers at state and municipal level decide to change the rules just for their little fiefdom. And they keep changing their minds.
The tz database is looking for the longest-lived identifier that accurately describes that geographic region to which the rules apply. Every time one region diverges from the norm, they need to accommodate the split. They chose continent and city names, because the historical perspective is that city names have remained in use longer than country names.
For your case, however, they have aliases. "US/Pacific" is an alias to America/Los_Angeles", as is "PST8PDT". Set and forget.
If the map let you pick any arbitrary point rather than having to pick a specific city in the TZ database, that would actually be a better way than a list of cities. See the discussion elsewhere in this thread about mapping Salt Lake City -> (Boise vs Denver).
(I don't think the TZ database contains the information to do this though, but maybe it should?)
I just fired up the selector on macOS Sequoia and I see Seattle, Portland etc. when I type in the combo box (I'm not near there right now). Guessing that you're probably just seeing a ip geolocation that detected your location as further away.
Whoah there, no, that's a huge pitfall of sharpened spikes as soon as you deal with events in the future.
If someone proposes an after-work party for "5:30 PM" at the Latverian office in Latverian time, that's not a fixed offset of seconds from now, it's actually a set of triggering conditions.
We can make a decent guess about when those conditions will be satisfied, but don't actually know until it finally happens. At any moment, the administration of Dr. Doom could arbitrarily change the country's clocks. They might skip over that entire hour, or the hour might repeat on that day, or the entire country might cease to exist.
Making a prediction in UTC and storing just that is a very bad idea, because you lost all the original context you need to recalculate a better prediction as things change. Storing the "5PM in Latverian" is how we keep that context.
Here the problem is that past "time" values and future "time" values should be different data types, e.g. "Time" and "FutureTime".
A past time value (e.g. the times of logged events) actually is a time value that is known and it should be stored as a TAI or UTC value and when desired it can be converted to any date/time format for presentation purposes.
In most cases, a future time value is not a known time value yet and it must be stored as a more complex data type, at the minimum including the local time and the time zone, but for more distant future dates preferably also including the exact geographic location, for the eventuality of changes in the time zone laws.
Therefore, both you and the poster to whom you have replied are right, but you are right only when talking about future time values, while the other poster was right only when talking about past time values.
This is not about "future" or "past" dates but (to use Temporal as a common language) whether the date is an Instant or a ZonedDateTime conceptually.
I think that's essentially what you mean, but it's an important distinction. It's use-case based. Making a data type time-based will not simplify, but only complicate things.
UTC helps store specific moments in time. Notably it does not solve for "dates" nor recurrence. Many of my hairs have been lost to third parties thinking they've created viable systems simply because they use UTC.
UTC or TAI are the right solution for storing past time values. Any other information is superfluous and it makes things more complicated than they should be.
Future "time" values are typically not time values. Therefore they must be stored using a different more complex data type, which contains all the information that will be necessary in the future to determine the corresponding time value.
Using the same data type to store both past time values and future time values is in most cases a serious programming mistake, which either wastes resources or is likely to cause bugs.
I wouldn’t say local time is superfluous, as it gives context.
If a historic event occurred at 0300 on Feb 15th, there’s a significant amount of information in knowing the local time. Was it 3am in London, when most people would be asleep. Or was it 7pm Friday night In San Francisco when people were on Valentine's dates, or was it 3pm on Saturday afternoon when people were having a bbq.
If you were to write “the accident occurred at 0300 UTC” then that would imply something very different depending on what the local time was at the time.
How about “the shop opened at 9am every day, without fail”.
Far more useful than “the shop opened at 1600UTC for half the year and 1700UTC for the other half”
I disagree. A stored value that was a future time value yesterday could become a past time value tomorrow. Keeping up with the invariant adds complexity because stored data would have to be migrated all the time.
That added complexity can be much worse than using zoned values for everything.
> A stored value that was a future time value yesterday could become a past time value tomorrow.
And that past time value can become a wrong time value if it was converted from a user's local time to UTC before a tzdata version change.
UTC only works for absolute time and accidentally works most of the time for wall time as perceived by humans. It's vaguely similar to how calculating money with floats accidentally works most of the time.
In either case, you still have to do a migration: you need to convert your old UTC stamp to a new one that represents the correct local time, or with what the grandparent proposed, just having it stored in the local time and converting it close to the time it actually occurs.
But the UTC -> UTC conversion is worse. You have to figure out which timezones changed in the new tzdata version, convert them to the new UTC value, then update tzdata. Most libraries seem to only support one tzdata version at any given time, so this is way more complex to me than just having the wall time stored so that it can be converted to the correct UTC value at "decision time".
> just having the wall time stored so that it can be converted to the correct UTC value at "decision time"
Well, this isn't unambiguous in all cases either unfortunately: 1:30 AM in Houston, TX (Central Time) on 3-Nov-2024 could be either 0630Z (Central Daylight Time) or 0730Z (Central Standard Time), since the clocks will have fallen back.
Yes, but it's vastly less ambiguous: ambiguity for one day between 1:00AM - 3:00AM out of the year vs ambiguity for all future dates and times.
Now you can prompt the user for their intent when the time change is known or expected. The ambiguity is now narrowed down to only the situations where the time change could not have been known in advance.
It's a similar painful insanity as: "Other currencies? Just convert them to US dollars on save, and store that number in the database, nice and easy, no problems."
Timezones are not static, and actually change somewhat frequently. A program that converts any given future time to UTC risks becoming incorrect about when that time is due to political changes that affect the timezone the given future time was in.
I must be the dumbest person in the world, then, because that's exactly what I've been doing on all my computers for 20 years (and I don't reside in Iceland).
Not parent poster, but: It creates annoyance and frustration for the end user, it creates new sources of error (especially when the end-user has to do time-conversions) and provides no actual benefits in terms of system correctness.
So instead of your settings sometimes being wrong and easily-fixed with a few clicks, you want them to be almost always wrong? :P
Again, I don't understand what pain-point or use-case is motivating this "set your laptop OS to UTC" proposal.
... Well, not unless it's some workaround for flawed software running on that machine, perhaps made by developers that misunderstood the business-domain of time zones.
> So instead of your settings sometimes being wrong and easily-fixed with a few clicks
It can't be easily fixed. Imagine I continuously change the OS's setting to always reflect the local time. Now I read a log of events happened last Tuesday. Was it when I was in Europe or when I was in the US? How should I read those timestamps? Then I compare two timestamps from last spring. They differ a few minutes, but one was before the switch to DST the other was after. Which one happened first?
> you want them to be almost always wrong?
I think "wrong" is relative, isn't it?
> Well, not unless it's some workaround for flawed software
Exactly the opposite: there used to be a SO from Redmond that didn't allowed you to set its internal clock to UTC. I think it's been corrected now.
> Imagine I continuously change the OS's setting to always reflect the local time. Now I read a log of events happened last Tuesday.
Those two things are unrelated, how frequently you changed timezone settings should have zero impact on your log... unless it means more "settings changed" entries. Changing your current timezone does not move things that already happened.
The event-log entries (A) shall be order-able by actual chronology, excepting relativistic effects, and (B) shall all display under some unified reporting timezone, whether that's hardcoded to be UTC, or the system timezone when exporting/displaying, or a time-zone chosen in an Event Viewer GUI.
If either (A) or (B) are false, that means you're dealing with worryingly flawed software from developers who weren't prepared to implement timezone logic.
> Now I read a log of events happened last Tuesday. Was it when I was in Europe or when I was in the US?
In all cases, your first step is to figure out where those real-world events fall relative to the log entries.
It will always be less work if the event-log display timezone happens to match one of the ones for your departure/arrival times.
> Then I compare two timestamps from last spring. They differ a few minutes, but one was before the switch to DST the other was after. Which one happened first?
Easy: The one that sorts earlier, and if you display logs in UTC they will be visually distinct as well.
I think we agree without understanding each other.
It must be possible to sort all system events in an "absolute time line". To do so, the system must know in every moment at what point of this "absolute time line" we are, so that it can stamp the event with such absolute time marker.
Now, we can make it coincide with any known TZ, but once set, we must not change it. I set it to UTC; you might prefer your home TZ, if you have a place you call "home". But then don't change it when you travel or when switching DST on and off!
Of course you can still change the TZ of the time that's displayed to you (so that it's synchronized with the local church's bells, for example, which is convenient and might avoid you a lot of misunderstanding with your local friends), but not the TZ the OS uses for itself.
I find that any choice of home TZ would be arbitrary, so UTC is the best choice.
I do this on all my workstations, phones, wall clocks, Google calendar, and everything. After a lot of frustration I found it the lesser of evils to just think in UTC regardless of where I am in the world, and convert for local people on the fly.
I have set my clock on UTC on all my workstations, desktops and laptops for many decades. This has been particularly convenient on the laptops used in business trips.
For many years, when I still had some other clocks besides those included in computers or mobile phones, e.g. wall clocks or wrist watches, those were also set in UTC, thus with no change between winter and DST.
I prefer to keep in mind the current offset of my local time from UTC, and also the offsets of a couple of places where people with whom I communicate frequently are located, and to add those offsets mentally to the displayed UTC time when that happens to be necessary in order to synchronize to some external event, like a meeting or the opening hours of some place. I schedule my own activities, e.g. eating or sleeping, in UTC.
This habit was triggered decades ago by the fact that I found much more annoying the hour change of all clocks to/from DST than changing in my mind the current offset of the local time from UTC, and also by the fact that the local time does not correspond with the solar time anyway, because I an not located on the center of the time zone, so if I want to know when it is noon, I have to also keep in mind the offset of the solar time from local time, which changes when DST applies. At least with UTC, that offset remains constant.
I do not consider myself dumb :-)
On the contrary, I consider that the legal time is designed for people who are so dumb that they cannot remember that during summer they should wake up and go to work earlier than in winter, the same as their ancestors did for many millennia. To be fair, their ancestors did not use a clock for this, but they woke up depending on the rising sun, which took care of this automatically.
I commented on the other post about how timezones bit me, continue to bite me even though I do everything in UTC now, and will probably bite me again in the future.
I also like that she’s able to reproduce it but I feel like this should have been a test check in the distro to ln the US zones as to not mess up older codebases.
In the end, standardizing is the right way to go. If you’re a maintainer, think about adding tests and checks for files that if moved might break things that depend on it. Maybe a service that watches for fd access to those and gives a warning, I don’t know what the best approach would be but it would be nice to have something at the user land level that said “Ahh ahh ahhh, you didn’t say the magic word”
The United States Government calls it "The Pacific Timezone." They define it, maintain it, and broadcast it's definition. They're the only entity with the authority to do so. That's what I'm using. I'm not using whatever the time happens to be in Los Angeles, I'm using the federal timezone definition. My timezone should absolutely be just "US/Pacific." Using "America/Los_Angeles" is _absolutely_ an abstraction and it's obviously entirely unnecessary.
Context on "THE ONE", a phrase used in this post, because it wasn't obvious to me initially.
https://rachelbythebay.com/w/2018/04/28/meta/
That's the problem with writing posts both of the "everyone else is doing things WRONG, those dang fools" (e.g. the series on RSS readers) and "oops, I did a stupid mistake, heh, TIL" styles and variety: the latter ones tend to attract comments from "The One" (oh noes) referencing the first kind of posts. Naturally, a humble person would simply read them, note them, and move on withouth replying — but a humble would person would not write the "everyone else is doing things WRONG, those dang fools" kind of posts either in the first place; and so we get the third kind of posts, the ones with "yeah, I did a small mistake, but I've admitted it myself, so no one else is allowed to criticize me; anyway..." disclaimer on the top.
P.S. I do distictly remember how a reply on HN to one of her earlier posts on RSS clients mentioned that her laments kinda miguided since her own feed doesn't set one very well-documented and basic cache-controlling HTTP header that most readers actually do respect; but some time later in her later post she described that header as matter-of-fact knowlewdge, no "I've learned about this one recently" remark or anything, and by that time, her RSS feed had started setting it.
I don't know, with her RSS saga, she actually provided a tool to test one's RSS feed reader and helped find bugs and this lead to fixes in many RSS tools, making things better for everyone. She put in the work. I find the approach quite constructive.
Well, yes, it did improve that particular area of software. Although for about 15 years that wasn't really problem for anyone who didn't self-host their blog on a potato attached to the Internet with a phone coupler and copper-wires; you can find comments at HN in the relevant discussions from the people who apparently serve about the same amount amount of (almost) static traffic she complains about while it costs them like $2 monthly or something. Now AI crawlers, those are quite a problem...
While I am personally glad that now there are less infuriatingly stupid network clients around (although, again, those never really amounted to all that much load), and probably adopting a rather caustic attitude at the authors of RSS clients was the only to force them to fix things, but even then: you can do more with a kind word and a gun than with just a gun. Besides, there is some unspoken etiquette between the content servers and content readers; a server that e.g. bans you for exceeding rate-limits when you open the "Full blog archives" page and middle-click at 10 promisingly named links to read them one after another is just rude, personal opinions of the hoster notwithstanding.
P.S. Seriously, max-age=155520? Your server/ISP can't handle serving a ~190 KiB (when gzipped) file even once a day, it has to be almost 2 days? Get it off the public Internet then.
Thanks, I missed it.
(I should note that in my crowd, references to this movie are always super-negative. "The One" gets damned to hell to eternally fight, but never win his battle.)
I'm not sure I understand the purpose of these blog posts for what is, at best, a simple bug in Debian. When I encounter something like this, I find steps to reproduce and file a bug. That's it.
If someone wants to get indignant and broadcast how terrible it is that a project (Debian in this case) is so terrible that they dare have a UX issue that is probably just an oversight, then they're entitled to do that but can also expect pushback where they aren't perfect either.
Rachel has been blogging for a long time, she knows what topics get clicks and stir up debate on social media.
The core issue is that tzdata files do not contain the time zone identifier. If you are unlucky in /etc/localtime is not a symbolic link, you have to scan the files in /usr/share/zoneinfo to find a match. PostgreSQL prefers shorter names: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit...
That's why "US" wins over "America".
Looking at that code I’m shocked that Postgres allows two-liner if statements without a matching {} (I’m sure someone pedantically will point out that I’m using the wrong terminology or that it was actually several lines of conditionals).
This practice is very bug prone, and has lead to high profile failures like goto fail
The project history goes back to 1982. There may have been rewrites in the later 80s, but it's some of the oldest C around, and a very conservative codebase (e.g. Linux kernel gets much more aggressive refactorings regularly).
That particular git repository has history imported from 1996 onward, but Postgres was a very established project by then: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit...
These days people might not blink an eye at gofmt/rustfmt rewriting the AST to clean it up, but those toolchains were built that way largley because automating anything about large C codebases is so hard.
Except this was new code.
Generally, large C projects have their own style that is followed whether the code is new or not.
And thus it’s surprising to me they haven’t changed their style moving forward when it’s known that this is error prone.
Large stable projects are very much wary of wide-scale changes their codebase. What they have is tested working by decades in production. Especially with C where tooling is brittle.
Let me put this way: If you submit a code prettifying patch to the Linux kernel, it will not be accepted. The risks aren't worth it.
The only real way forward is full migration away from C, for which a better scope is a separate project.
These days, there are compiler diagnostics for that. There's also a pgindent tool, which will align the visual presentation of the code with its syntactic structure.
What issue are you taking with the code? Line breaks in the condition?
Presumably the last if statement in the diff.
There aren’t {} brackets after the if
Are you saying they should always be present? Or only when the condition takes multiple lines; i.e. do you take issue with the ifs in zone_name_pref too?
Personally I think the indentation does a good enough job here.
Yes I’m saying they should always be present. It is known to otherwise be error prone, which is why new c-like languages do not permit this (eg go) nor do many style guides (https://google.github.io/styleguide/cppguide.html#Formatting...)
It's worth noting that a new installation of Debian will still display the same Eastern, Central, Mountain, Pacific menu to the user as shown in the screenshot. It just maps those to the non-deprecated names now.
Read the previous blog post [0] -- this one is disjointed without it. I dislike TZ selectors that use locations (cities, countries, etc.). Let PDT be PDT(-8) and PST be PST(-7). Why do I need to choose Cupertino, CA (or LA in the blog post example) -- locations over 1k miles away from me? And while I certainly understand where Cupertino is and how it relates to my TZ, what if someone else doesn't? Cupertino isn't a major population center.
Anyway, poor UX. But of course TZ names could also be argued as poor UX. What if you just did PST/PDT as Los Angeles, CA; Oregon, OR, and Seattle, WA all on separate line items? Sure, it's duplicate data but a backend system (Postgres config files, say) should only store the value of the TZ, i.e. -7 / -8. At least a user could recognize 'oh, I drive to xyz major city occasionally, that's the choice I want'.
To keep ranting, I checked macOS 15 TZ selector for PDT/PST. The selector itself is labeled "Closest city". It has numerous locations in California, a few in Nevada, and a couple in Mexico. No cities in Oregon, Washington, or Idaho (and Hyder, AK... neat [1]).
Closest is a stretch, like I said, over 1K miles from LA. But why several California cities, including minor ones like Oceanside (~175K people), but nothing in Oregon (Eugene, also 175K), Portland (652K), or Washington - Tacoma (220K), Seattle (740K). Note I did not look for the smallest city in the macOS CA list.
It's weird to me. Maybe it's because Oregon == Intel and Washington == Microsoft. ;-)
[0] https://rachelbythebay.com/w/2025/09/11/debtz/
[1] https://en.wikipedia.org/wiki/Pacific_Time_Zone#United_State...
> Anyway, poor UX. But of course TZ names could also be argued as poor UX. What if you just did PST/PDT as Los Angeles, CA; Oregon, OR, and Seattle, WA all on separate line items? Sure, it's duplicate data but a backend system (Postgres config files, say) should only store the value of the TZ, i.e. -7 / -8.
Because that doesn't tell you when the timezone changes. Two locales can share timezones but start or end daylight savings time at different times.
For instance, Cuba and Florida are both -4 / -5, but Cuba starts and ends daylight savings time 2 hours and 1 hour, respectively, before Florida.
Then there's the fact that locales, once in a while, will change what timezone they're in (like Samoa in 2011) or stop/start observing daylight savings time. Having the timezone set to a place largely solves this problem.
Maybe it could be a forcing function for the less-majority DST-rule countries to align to the majority, once they figure out that their IT systems have trouble twice a year they'll be sure to vote on it.
Ideally though, just get rid of DST.
> Let PDT be PDT(-8) and PST be PST(-7). Why do I need to choose Cupertino, CA (or LA in the blog post example)
Whether daylight savings time is being used at a given location at a given time of year is a matter of government policy. The city-based timezone selectors should handle that automatically based on the jurisdiction you choose.
> Sure, it's duplicate data but a backend system (Postgres config files, say) should only store the value of the TZ, i.e. -7 / -8.
Then the time may be wrong for half the year depending on where you are.
> The city-based timezone selectors
There's no America/Salt_Lake_City you're recommended to use America/Boise instead. The people in Salt Lake City are about as far away from Boise as you can get and Salt Lake City is more easily recognized as a landmark then Boise. The process of choosing which cities should be landmark cities comes across as faulty and uninformed.
The reason why certain cities get entries is because sometime after time began (1970-01-01), the region they're in changed their timezone (usually adopting or dropping DST or changing when it began). Those changes need to be recorded in the timezone database. The largest city in the affected area is typically chosen to be representative of the area.
Boise has its own entry because in 1974, the Emergency Daylight Time Act shifted when DST began in Southern Idaho and eastern Oregon. Boise is the largest city in the region.
Technically, if you're in Salt Lake City, you should be using America/Denver, not Boise because of this, otherwise if you say, opened a calendar from 1974, everything will be off by an hour.
If Utah made DST there begin a day earlier this year, Salt Lake City would probably get an entry too.
I think for the US, they should ensure tzdata contains at least one city for every state. That’s what they do for Australia. Now, it so happens their current rules-only add city if in recent decades it had distinct time zone rules-happen to produce that outcome for Australia, because in Australia time is a state issue and historically every state decided for itself whether to have daylight savings and when to begin/end it. Still, I think they should amend their rules to say “capital and/or largest city for every first-level subdivision of major countries”, given some reasonably objective definition of “major” (e.g. G20 nations)
The problem in the US is that time zone boundaries very frequently do not match state boundaries.
It’s common for major cities to be located on rivers that are state boundaries, the area around the city uses the same timezone, and one of the states has a timezone boundary in the middle. Indiana has many tz database entries because of this kind of thing.
There are other fun cases like the Navajo Nation in Arizona.
14 states have more than one time zone[0].
I live in South Dakota, which is one of them—the Mountain/Central timezone boundary within the state follows the Missouri river. (Locals refer to "East River" and "West River" to refer to the two halves of the state. The capital, Pierre, is technically East River, but is right on the banks, almost dead-center.)
[0]: https://simple.wikipedia.org/wiki/List_of_U.S._states_and_te...
Australia has an entry for a major city per state not because someone decided it was a good idea, but for the same reason Boise got one - they were the largest city in a jurisdiction that sometime after 1970 changed its timezone so it didn't match anyone else which necessitated adding an entry in order to record the unique timezone rules for them.
For instance, both Sydney and Melbourne both have entries because Victoria and New South Wales have started/ended daylight savings time in various years since 1970 on different dates like in 1990 when in Victoria it ended on March 18 while in New South Wales it ended on March 4.
It's also why Broken Hill has an entry despite being in New South Wales, they're in their own timezone.
There's a tradeoff between subdivisions per country and the UX that causes for timezine picker dropdowns in making everyone else scroll past all the US, Canada, India etc. subdivisions
Given that there's 600 entries anyway, you really want to use one of those dropdowns that also lets people search by substring. Or a clickable map.
You can't really escape the fact Europe/ is going to be after Africa/ and America/ and Antarctica/ and Asia/ and Australia/ and Canada/ and Etc/
Ubuntu has had a map-based graphical picker for a long while.
> Those changes need to be recorded in the timezone database.
The issue with this thinking is that all existing datimes referring to that region will continue using the old timezone because the new one didn't exist yet.
Salt Lake City is a 4.5-5 hour drive from Boise. If you want a better example, there are no cities in Texas in the list, and Chicago is a lot further away than Boise is from Salt Lake City!
Yep, I pick Chicago for my timezone and it's roughly a 7 hour drive. I think have major cities represent broad timezones is a good UX tradeoff.
> The process of choosing which cities should be landmark cities comes across as faulty and uninformed.
I think it's unlikely they're chosen as landmark cities. More likely, timezones were uniform, then some government likely did their own thing in their jurisdiction. The change was then represented as a new timezone named after the place where the change is centered. IOW, the names have more to do with some random divergence that happened at some point in history, rather than what landmarks are the most recognized for today's timezones. Re: Boise & Salt Lake City, maybe Boise was the first to do their own thing while Salt Lake City had a different timezone. Maybe Salt Lake City later decided to adjust their timezone to fit Boise's to facilitate commerce between their states.
I run all my clocks and computers in UTC. I hate that I have to select "Reykjavik" in the Ubuntu installer instead of just "UTC".
Have you had any interesting pros/cons to running your clocks UTC?
You can't just go by time zone names because there are weird exceptions, like most of Arizona not doing DST. Then there's Indiana, which didn't do DST until 20 years ago, and there are some counties that switched time zones when the DST law took effect... if you're in one of those counties will you just accept old timestamps being an hour off? Granted, this gradually becomes less of an issue the further we get from the change. But nothing guarantees that there won't be further changes in the future.
And that's just the US, there's almost 200 other countries each with their own laws.
> But nothing guarantees that there won't be further changes in the future.
There are guarantees that there will be changes in the future! There are changes regularly, some expected, some not. In some countries the suspension of DST due to Ramadan is decided on the first night of Ramadan itself when a group of elders look at the moon and decide whether Ramadan starts tonight, or tomorrow.
https://www.cnn.com/2025/02/27/travel/ramadan-start-crescent...
Even abbreviations have issues. PST (UTC+8) is also Philippine Standard Time. EST could mean Eastern Standard Time in Australia, granted that nowadays is AEST.
Timezones are such a headache. Obviously even UTC for a location varies depending on the time of year.
Even the International Space Station shifted timezones from Houston time to UTC+0.
Curiosity and Perseverance's clocks are UTC but operations run on LMST (local mean solar time) Gale Crater and LMST Jezero Crater- their landing locations. That point is moot until humans start spinning up VMs on Mars which they will one day.
> Obviously even UTC for a location varies depending on the time of year.
The offset from UTC for a location varies depending on time of year but UTC definitionally has a zero offset throughout the year.
If you’re in the Europe/London time zone your time is equal to GMT/UTC (offset zero) for half the year and BST (offset +1) for the other half.
In other words we have two different types here: Timezones based on location where the UTC offset varies, and the UTC offset itself (like +0100/BST or +0000/GMT/Z.)
I remember getting yelled at by an American on Reddit once, when I asked what they meant by EST. Because of course America is the only country that shouldn't have to use country-prefixed versions of anything.
And of course, saying 'EST' doesn't actually tell me what fucking time something is happening. Telling me what UTC offset EST is, does.
> Anyway, poor UX. But of course TZ names could also be argued as poor UX. What if you just did PST/PDT as Los Angeles, CA; Oregon, OR, and Seattle, WA all on separate line items?
If your application can access the current location you don't need to expose a TZ selector to the user. You can figure out what time zone database sector you're in automatically.
https://en.wikipedia.org/wiki/List_of_tz_database_time_zones...
> Sure, it's duplicate data but a backend system (Postgres config files, say) should only store the value of the TZ, i.e. -7 / -8.
Your backend needs to store location because places can switch time zones. The reason for the seemingly arbitrary list of cities is they each define a region where clocks have been synchronized since 1970.
I’m not letting applications access my location just to let it pick a time zone.
IP geolocation is often wrong and inaccurate. I’ve had a VPS whose IP was geolocated 360 km away, in another country and time zone. But even with residential IPs, they might be pointing to a different time zone in countries with multiple zones.
> Your backend needs to store location because places can switch time zones.
For the event, your backend only needs to store the timestamp in a timestamptz field and make sure that clients set the correct time zone on session start (this you might want the backend to store in the database too, but probably in the users table).
A bit of an edge case, but there's also the problem that the time zone you pick today might not be the time zone you have tomorrow: The jurisdiction you're in can change what their clocks use on an institutional whim.
It's very unlikely, but tomorrow some state or major city in PST could decide to add 15 minutes to all their wall clocks. Should your computer's clock change? That depends on what you're using it for...
> Let PDT be PDT(-8) and PST be PST(-7)
The problem is both the US and Australia have “EST/EDT” - the Australian version sometimes has an A stuck on the front to disambiguate it from the US timezone, but that isn’t always done (especially given some systems insist timezone abbreviations can be max 3 characters). And the problem with disambiguating on the basis of UTC offsets is you’d be surprised by how many people have no clue what any of them are. But “Americas” vs “Australia”, they’ll get that right
I suspect a large number of users might choose PST if in California, when they really mean PST/PDT. Or perhaps in the summer they would semi-correctly choose PDT.
Choosing a large city you know shares your time zone does make things a bit more “human“.
This absolutely would happen. Most Americans I know refer to their timezone as EST/CST/MST/PST even after March.
I’m currently working at one of the world’s largest consumer banks, and for a company that really should care about the accuracy of such things, I see “EST’ frequently all summer long.
In my experience, Brits refer to their time as "GMT" whether or not DST is in effect.
True; I should have said "most people refer to their local timezone in that way". (The reason I didn't was because at the time, I was referring to those specific timezones, not because I was picking on Americans.)
> I dislike TZ selectors that use locations (cities, countries, etc.). Let PDT be PDT(-8) and PST be PST(-7).
You can choose that. Set your timezone to Etc/GMT-8. Then, at the exact time your political jurisdiction mandates switching over to PST, go to all your computers and switch them all to Etc/GMT-7. Then do the same thing next year for switching back.
What? That's bad UX as well? Well then, you have to name the correct political jurisdiction that mandates the timezone rules where you live. And that's hard, because so many little tinkerers at state and municipal level decide to change the rules just for their little fiefdom. And they keep changing their minds.
The tz database is looking for the longest-lived identifier that accurately describes that geographic region to which the rules apply. Every time one region diverges from the norm, they need to accommodate the split. They chose continent and city names, because the historical perspective is that city names have remained in use longer than country names.
For your case, however, they have aliases. "US/Pacific" is an alias to America/Los_Angeles", as is "PST8PDT". Set and forget.
> For your case, however, they have aliases. "US/Pacific" is an alias to America/Los_Angeles", as is "PST8PDT". Set and forget.
Except when you can't forget, as in the original case for this blog post in the first place.
> You can choose that. Set your timezone to Etc/GMT-8.
In the Debian installer yes, but the stupid Ubuntu installer forces you to pick from a map.
If the map let you pick any arbitrary point rather than having to pick a specific city in the TZ database, that would actually be a better way than a list of cities. See the discussion elsewhere in this thread about mapping Salt Lake City -> (Boise vs Denver).
(I don't think the TZ database contains the information to do this though, but maybe it should?)
Why would you use Ubuntu in the first place?
Because it works? Why wouldn't you?
The good option is not to yell at clouds but to open a bug report, provide a patch, use Debian or change it after install.
I change it after install, but let's be realistic: I'm not Linus Torvalds or Guido von Rustum, it's not like they would listen to me or take my patch.
Offset alone is not enough because different TZ names also point to different DST schedules (current and historic) and past changes.
You can look at the tz data files to see what that looks like.
I just fired up the selector on macOS Sequoia and I see Seattle, Portland etc. when I type in the combo box (I'm not near there right now). Guessing that you're probably just seeing a ip geolocation that detected your location as further away.
I'm curious as to what people in Phoenix would select as their timezone under your proposed solution?
My prize for worst time zone UI still goes to Google calendar.
If you want to create an event in a different time zone from your default the select picker it gives you is utterly incomprehensible.
I can't even find the time zone for New York/US eastern in it!
Screenshot here: https://static.simonwillison.net/static/2024/google-calendar...
isn't it at GMT-4 Eastern Time - New York?
Here's the search results you get if you type "eastern" in that interface: https://gist.github.com/simonw/c2a73e40bbc87b8c25333207c551f...
Typing "New York" gets zero results.
Even knowing the exact name of the timezone I want I still can't find it in that UI!
At least for me, since it's ordered by offset, i just scroll to the approximate offset rather than try to type.
On android, "eastern" similarly results in a mess of results (but eastern is a bad name anyway...), "new york" does find it.
The desktop web version seems to have no type-in search functionality.
In the Android app typing "new y" gives
if one is serious, one just chooses UTC.
one can play with timezones all they want, but in the end it's a presentation issue.
> in the end it's a presentation issue.
Whoah there, no, that's a huge pitfall of sharpened spikes as soon as you deal with events in the future.
If someone proposes an after-work party for "5:30 PM" at the Latverian office in Latverian time, that's not a fixed offset of seconds from now, it's actually a set of triggering conditions.
We can make a decent guess about when those conditions will be satisfied, but don't actually know until it finally happens. At any moment, the administration of Dr. Doom could arbitrarily change the country's clocks. They might skip over that entire hour, or the hour might repeat on that day, or the entire country might cease to exist.
Making a prediction in UTC and storing just that is a very bad idea, because you lost all the original context you need to recalculate a better prediction as things change. Storing the "5PM in Latverian" is how we keep that context.
Here the problem is that past "time" values and future "time" values should be different data types, e.g. "Time" and "FutureTime".
A past time value (e.g. the times of logged events) actually is a time value that is known and it should be stored as a TAI or UTC value and when desired it can be converted to any date/time format for presentation purposes.
In most cases, a future time value is not a known time value yet and it must be stored as a more complex data type, at the minimum including the local time and the time zone, but for more distant future dates preferably also including the exact geographic location, for the eventuality of changes in the time zone laws.
Therefore, both you and the poster to whom you have replied are right, but you are right only when talking about future time values, while the other poster was right only when talking about past time values.
This is not about "future" or "past" dates but (to use Temporal as a common language) whether the date is an Instant or a ZonedDateTime conceptually.
I think that's essentially what you mean, but it's an important distinction. It's use-case based. Making a data type time-based will not simplify, but only complicate things.
[0] https://tc39.es/proposal-temporal/docs/
UTC helps store specific moments in time. Notably it does not solve for "dates" nor recurrence. Many of my hairs have been lost to third parties thinking they've created viable systems simply because they use UTC.
UTC or TAI are the right solution for storing past time values. Any other information is superfluous and it makes things more complicated than they should be.
Future "time" values are typically not time values. Therefore they must be stored using a different more complex data type, which contains all the information that will be necessary in the future to determine the corresponding time value.
Using the same data type to store both past time values and future time values is in most cases a serious programming mistake, which either wastes resources or is likely to cause bugs.
I wouldn’t say local time is superfluous, as it gives context.
If a historic event occurred at 0300 on Feb 15th, there’s a significant amount of information in knowing the local time. Was it 3am in London, when most people would be asleep. Or was it 7pm Friday night In San Francisco when people were on Valentine's dates, or was it 3pm on Saturday afternoon when people were having a bbq.
If you were to write “the accident occurred at 0300 UTC” then that would imply something very different depending on what the local time was at the time.
How about “the shop opened at 9am every day, without fail”.
Far more useful than “the shop opened at 1600UTC for half the year and 1700UTC for the other half”
Moreover, you don’t want the recorded local time to change just because the tz database is being updated.
In theory historic times wouldn’t change as t data would be updated before the change.
In reality that’s not always the case.
I disagree. A stored value that was a future time value yesterday could become a past time value tomorrow. Keeping up with the invariant adds complexity because stored data would have to be migrated all the time.
That added complexity can be much worse than using zoned values for everything.
> A stored value that was a future time value yesterday could become a past time value tomorrow.
And that past time value can become a wrong time value if it was converted from a user's local time to UTC before a tzdata version change.
UTC only works for absolute time and accidentally works most of the time for wall time as perceived by humans. It's vaguely similar to how calculating money with floats accidentally works most of the time.
I don't want this scenario:
In either case, you still have to do a migration: you need to convert your old UTC stamp to a new one that represents the correct local time, or with what the grandparent proposed, just having it stored in the local time and converting it close to the time it actually occurs.But the UTC -> UTC conversion is worse. You have to figure out which timezones changed in the new tzdata version, convert them to the new UTC value, then update tzdata. Most libraries seem to only support one tzdata version at any given time, so this is way more complex to me than just having the wall time stored so that it can be converted to the correct UTC value at "decision time".
> just having the wall time stored so that it can be converted to the correct UTC value at "decision time"
Well, this isn't unambiguous in all cases either unfortunately: 1:30 AM in Houston, TX (Central Time) on 3-Nov-2024 could be either 0630Z (Central Daylight Time) or 0730Z (Central Standard Time), since the clocks will have fallen back.
Yes, but it's vastly less ambiguous: ambiguity for one day between 1:00AM - 3:00AM out of the year vs ambiguity for all future dates and times.
Now you can prompt the user for their intent when the time change is known or expected. The ambiguity is now narrowed down to only the situations where the time change could not have been known in advance.
It's a similar painful insanity as: "Other currencies? Just convert them to US dollars on save, and store that number in the database, nice and easy, no problems."
This is a false analogy. Currencies are volatile whereas timezones are static and rule based.
Converting timestamps between time zones is perfectly reversible while there is a loss of information when you convert a value to a new currency.
Timezones are not static, and actually change somewhat frequently. A program that converts any given future time to UTC risks becoming incorrect about when that time is due to political changes that affect the timezone the given future time was in.
> Converting timestamps between time zones is perfectly reversible while there is a loss of information when you convert a value to a new currency.
False. This scenario absolutely does happen:
Running UTC as a clock on an end user workstation is about the dumbest thing you can do (unless they reside in UTC).
I must be the dumbest person in the world, then, because that's exactly what I've been doing on all my computers for 20 years (and I don't reside in Iceland).
Let's hear why you think this.
Not parent poster, but: It creates annoyance and frustration for the end user, it creates new sources of error (especially when the end-user has to do time-conversions) and provides no actual benefits in terms of system correctness.
What problem are you thinking it would solve?
> What problem are you thinking it would solve?
Traveling.
So instead of your settings sometimes being wrong and easily-fixed with a few clicks, you want them to be almost always wrong? :P
Again, I don't understand what pain-point or use-case is motivating this "set your laptop OS to UTC" proposal.
... Well, not unless it's some workaround for flawed software running on that machine, perhaps made by developers that misunderstood the business-domain of time zones.
> So instead of your settings sometimes being wrong and easily-fixed with a few clicks
It can't be easily fixed. Imagine I continuously change the OS's setting to always reflect the local time. Now I read a log of events happened last Tuesday. Was it when I was in Europe or when I was in the US? How should I read those timestamps? Then I compare two timestamps from last spring. They differ a few minutes, but one was before the switch to DST the other was after. Which one happened first?
> you want them to be almost always wrong?
I think "wrong" is relative, isn't it?
> Well, not unless it's some workaround for flawed software
Exactly the opposite: there used to be a SO from Redmond that didn't allowed you to set its internal clock to UTC. I think it's been corrected now.
> Imagine I continuously change the OS's setting to always reflect the local time. Now I read a log of events happened last Tuesday.
Those two things are unrelated, how frequently you changed timezone settings should have zero impact on your log... unless it means more "settings changed" entries. Changing your current timezone does not move things that already happened.
The event-log entries (A) shall be order-able by actual chronology, excepting relativistic effects, and (B) shall all display under some unified reporting timezone, whether that's hardcoded to be UTC, or the system timezone when exporting/displaying, or a time-zone chosen in an Event Viewer GUI.
If either (A) or (B) are false, that means you're dealing with worryingly flawed software from developers who weren't prepared to implement timezone logic.
> Now I read a log of events happened last Tuesday. Was it when I was in Europe or when I was in the US?
In all cases, your first step is to figure out where those real-world events fall relative to the log entries.
It will always be less work if the event-log display timezone happens to match one of the ones for your departure/arrival times.
> Then I compare two timestamps from last spring. They differ a few minutes, but one was before the switch to DST the other was after. Which one happened first?
Easy: The one that sorts earlier, and if you display logs in UTC they will be visually distinct as well.
I think we agree without understanding each other.
It must be possible to sort all system events in an "absolute time line". To do so, the system must know in every moment at what point of this "absolute time line" we are, so that it can stamp the event with such absolute time marker.
Now, we can make it coincide with any known TZ, but once set, we must not change it. I set it to UTC; you might prefer your home TZ, if you have a place you call "home". But then don't change it when you travel or when switching DST on and off!
Of course you can still change the TZ of the time that's displayed to you (so that it's synchronized with the local church's bells, for example, which is convenient and might avoid you a lot of misunderstanding with your local friends), but not the TZ the OS uses for itself.
I find that any choice of home TZ would be arbitrary, so UTC is the best choice.
I do this on all my workstations, phones, wall clocks, Google calendar, and everything. After a lot of frustration I found it the lesser of evils to just think in UTC regardless of where I am in the world, and convert for local people on the fly.
Thing is... noone resides in UTC at all.
Reykjavik lives all year round in UTC
Places do not lie in UTC, data does. Iceland follows Western European Time (WET), which has no offset to UTC.
So does a large part of Western Africa.
I have set my clock on UTC on all my workstations, desktops and laptops for many decades. This has been particularly convenient on the laptops used in business trips.
For many years, when I still had some other clocks besides those included in computers or mobile phones, e.g. wall clocks or wrist watches, those were also set in UTC, thus with no change between winter and DST.
I prefer to keep in mind the current offset of my local time from UTC, and also the offsets of a couple of places where people with whom I communicate frequently are located, and to add those offsets mentally to the displayed UTC time when that happens to be necessary in order to synchronize to some external event, like a meeting or the opening hours of some place. I schedule my own activities, e.g. eating or sleeping, in UTC.
This habit was triggered decades ago by the fact that I found much more annoying the hour change of all clocks to/from DST than changing in my mind the current offset of the local time from UTC, and also by the fact that the local time does not correspond with the solar time anyway, because I an not located on the center of the time zone, so if I want to know when it is noon, I have to also keep in mind the offset of the solar time from local time, which changes when DST applies. At least with UTC, that offset remains constant.
I do not consider myself dumb :-)
On the contrary, I consider that the legal time is designed for people who are so dumb that they cannot remember that during summer they should wake up and go to work earlier than in winter, the same as their ancestors did for many millennia. To be fair, their ancestors did not use a clock for this, but they woke up depending on the rising sun, which took care of this automatically.
Doing this at the system level was one of the better ideas to come out of unix.
In an operating system especially good for multi-user remote access, why would you assume all your users are in the same timezone?
Timezone is very much a user interface issue.
I commented on the other post about how timezones bit me, continue to bite me even though I do everything in UTC now, and will probably bite me again in the future.
I also like that she’s able to reproduce it but I feel like this should have been a test check in the distro to ln the US zones as to not mess up older codebases.
In the end, standardizing is the right way to go. If you’re a maintainer, think about adding tests and checks for files that if moved might break things that depend on it. Maybe a service that watches for fd access to those and gives a warning, I don’t know what the best approach would be but it would be nice to have something at the user land level that said “Ahh ahh ahhh, you didn’t say the magic word”
Discussion about previous article in series:
Debian 13, Postgres, and the US time zones - https://news.ycombinator.com/item?id=45218111 - Sept 2025 (142 comments)
Title should involve "US/*", not just "US".
Cumbersome read. I gave up.
> I got to wondering... why did I pick "US/Pacific", anyway?
That's what the authority that defines the zone calls it. Using any other name is adding a useless layer of abstraction.
It is not, that’s the whole point of the blog post this one follows up on.
The United States Government calls it "The Pacific Timezone." They define it, maintain it, and broadcast it's definition. They're the only entity with the authority to do so. That's what I'm using. I'm not using whatever the time happens to be in Los Angeles, I'm using the federal timezone definition. My timezone should absolutely be just "US/Pacific." Using "America/Los_Angeles" is _absolutely_ an abstraction and it's obviously entirely unnecessary.