> 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 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.
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...
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.
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.
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
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.
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.