7 ms·

> But it's possible that between now and 2030 they might adopt Central European (Summer) Time[1], or retry British Double Summer Time[2], or scrap daylight savi

> But it's possible that between now and 2030 they might adopt Central European (Summer) Time[1], or retry British Double Summer Time[2], or scrap daylight savings entirely. Yes, and maybe East London secedes from the UK and uses a different time zone, so Europe/London doesn't specify the time zone you meant, anymore. This might not be likely for London, but if it's in the countryside of a less stable country and you just specified the time zone as the capital city, this might happen. I prefer time formats that are actually implementable and don't depend on a large database that can change at any moment.

koliber 3y ago
The current time formats depend on databases that can change at any time. I haven’t found one that is implementable and usable in the real world that does not depend on something that can be changed. Countries change. Timezones change by decree. This is a pain but it’s the real world and our tools need to be able to deal with it. I don’t like it either, and no one cares, nor should they. Reality trumps preference.
crote 3y ago
The problem with ISO 8601 is that it isn't properly implementable. Anything except Zulu time is basically broken. The tz database is updated on average every two months, and that doesn't happen without reason. Countries keep changing their timezones, and a rather high-profile one is the European Union's plan to get rid of DST over the next few years. This is already happening in Greenland this year. Some Muslim-majority countries also like to make their DST depend on Ramadan - which falls on a different and somewhat unpredictable date every year. Like it or not, if your code uses future dates and does not rely on "Europe/London"-style timezones, you will be slowly corrupting your data.
- mike_hock 3y ago
  > Anything except Zulu time is basically broken. How so? 2030-07-01T18:00:00+01:00 is a well-defined point in time, is it not? It may or may not be local time in London, but it's unambiguous. July 1st 2030, at 6pm, Europe/London is not. What's broken is the idea that you can somehow standardize "local time at a particular place" in a way that magically survives any arbitrary policy change. > Some Muslim-majority countries also like to make their DST depend on Ramadan - which falls on a different and somewhat unpredictable date every year. Thus proving that what you want does not exist and cannot exist.
  - tux1968 3y ago
    > How so? 2030-07-01T18:00:00+01:00 is a well-defined point in time, is it not? It may or may not be local time in London, but it's unambiguous. Being unambiguous isn't helpful if it is wrong. It is a very common desire to want to set a meeting based on the local time of a destination. The only future-proof way to store such a time, is to remember the destination and the desired local time. This is the only way the proper moment can be calculated and kept in sync with reality. The unfortunate fact is, the local time could be altered by decree, in any number of ways, in the interim timespan between setting a reminder, and when it happens.
    - calfuris 3y ago
      Even that isn't guaranteed to work, because different sets of people in the same place might have different time zones based on political affiliation. That's rare, but it has happened so it certainly could happen again.
  - lmm 3y ago
    > How so? 2030-07-01T18:00:00+01:00 is a well-defined point in time, is it not? It may or may not be local time in London, but it's unambiguous. It's a redundant way of writing 2030-07-01T17:00:00Z which only serves to cause confusion (it misleadingly looks like a local time, but it isn't). TAI or equivalent are useful; symbolic timezones are useful; numeric time offsets are useless and there's no benefit from having them be part of the standard. > Thus proving that what you want does not exist and cannot exist. Of course it does; 2030-07-01T18:00 Africa/Casablanca is a real time that humans will have no trouble attending a meeting at, and nor will computers as long as they've been keeping their zone file up to date. All we need is a standard for storing and interchanging it on computers.
    - GoblinSlayer 3y ago
      It's close enough to be useful, more obvious when you have a big offset like +12.
      - 3y ago

koliber 3y ago

The current time formats depend on databases that can change at any time. I haven’t found one that is implementable and usable in the real world that does not depend on something that can be changed. Countries change. Timezones change by decree. This is a pain but it’s the real world and our tools need to be able to deal with it. I don’t like it either, and no one cares, nor should they. Reality trumps preference.

crote 3y ago

The problem with ISO 8601 is that it isn't properly implementable. Anything except Zulu time is basically broken. The tz database is updated on average every two months, and that doesn't happen without reason. Countries keep changing their timezones, and a rather high-profile one is the European Union's plan to get rid of DST over the next few years. This is already happening in Greenland this year. Some Muslim-majority countries also like to make their DST depend on Ramadan - which falls on a different and somewhat unpredictable date every year. Like it or not, if your code uses future dates and does not rely on "Europe/London"-style timezones, you will be slowly corrupting your data.

mike_hock 3y ago
> Anything except Zulu time is basically broken. How so? 2030-07-01T18:00:00+01:00 is a well-defined point in time, is it not? It may or may not be local time in London, but it's unambiguous. July 1st 2030, at 6pm, Europe/London is not. What's broken is the idea that you can somehow standardize "local time at a particular place" in a way that magically survives any arbitrary policy change. > Some Muslim-majority countries also like to make their DST depend on Ramadan - which falls on a different and somewhat unpredictable date every year. Thus proving that what you want does not exist and cannot exist.
- tux1968 3y ago
  > How so? 2030-07-01T18:00:00+01:00 is a well-defined point in time, is it not? It may or may not be local time in London, but it's unambiguous. Being unambiguous isn't helpful if it is wrong. It is a very common desire to want to set a meeting based on the local time of a destination. The only future-proof way to store such a time, is to remember the destination and the desired local time. This is the only way the proper moment can be calculated and kept in sync with reality. The unfortunate fact is, the local time could be altered by decree, in any number of ways, in the interim timespan between setting a reminder, and when it happens.
  - calfuris 3y ago
    Even that isn't guaranteed to work, because different sets of people in the same place might have different time zones based on political affiliation. That's rare, but it has happened so it certainly could happen again.
- lmm 3y ago
  > How so? 2030-07-01T18:00:00+01:00 is a well-defined point in time, is it not? It may or may not be local time in London, but it's unambiguous. It's a redundant way of writing 2030-07-01T17:00:00Z which only serves to cause confusion (it misleadingly looks like a local time, but it isn't). TAI or equivalent are useful; symbolic timezones are useful; numeric time offsets are useless and there's no benefit from having them be part of the standard. > Thus proving that what you want does not exist and cannot exist. Of course it does; 2030-07-01T18:00 Africa/Casablanca is a real time that humans will have no trouble attending a meeting at, and nor will computers as long as they've been keeping their zone file up to date. All we need is a standard for storing and interchanging it on computers.
  - GoblinSlayer 3y ago
    It's close enough to be useful, more obvious when you have a big offset like +12.
    - 3y ago