3 ms·

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 wrongl

by 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...
    - zahlman 1y ago
      How and where, in principle, do you suppose it should (be able to) do so, given the functionality? It's just localizing timestamps, and the result might bubble through multiple layers of software before being presented to anyone. 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.
      - lmm 1y ago
        > How and where, in principle, do you suppose it should (be able to) do so, given the functionality? 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.
arielcostas 1y ago
> 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). 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.
- rlpb 1y ago
  > ...I have the option to select..."(UTC+0) Dublin, Edinburgh, Lisbon, London" 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.
  - raverbashing 1y ago
    > In summer, London is not UTC+0. They mean "UTC+0 ignoring DST", but that is not useful 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
    - donalhunt 1y ago
      Tell that to Ireland where we observe Irish Standard Time during the summer (and GMT during the winter).

by rlpb 1y ago

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...
  - zahlman 1y ago
    How and where, in principle, do you suppose it should (be able to) do so, given the functionality? It's just localizing timestamps, and the result might bubble through multiple layers of software before being presented to anyone. 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.
    - lmm 1y ago
      > How and where, in principle, do you suppose it should (be able to) do so, given the functionality? 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.

arielcostas 1y ago

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

rlpb 1y ago
> ...I have the option to select..."(UTC+0) Dublin, Edinburgh, Lisbon, London" 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.
- raverbashing 1y ago
  > In summer, London is not UTC+0. They mean "UTC+0 ignoring DST", but that is not useful 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
  - donalhunt 1y ago
    Tell that to Ireland where we observe Irish Standard Time during the summer (and GMT during the winter).