4 ms·

> ISO 8601 does NOT work with future dates. It does not work with cross border appointment booking. Why is this the case? Is it some time zone shenanigans?

rendaw 1y ago
And what format does work for future dates? Or do you mean that ISO 8601 doesn't work but RFC 3339 does work or some other updated ISO/RFC format?
- mattmanser 1y ago
  I'm not dealing with it anymore, I was when I worked in a couple of restaurant focused SaSSes. Someone else has mentioned RFC 9557. So you might be able to deal with it with 8601 for past dates and 9557 for future.
mattmanser 1y ago
Timezones change, more frequently than you realize. Some countries even used to change when summer time started regularly. It's got better than it used to be afaik. Also you need to take into account where the user is going to be. With future dates, time is relative. So at the very least you often need the time + the timezone of the location. Book me a table at 8, means book me a table in Berlin time at 8, not in San Francisco time at 8. Same with displaying future dates, you need the context of where.
- Philip-J-Fry 1y ago
  This is nothing to do with ISO 8601 though. You can represent time zones with that format. So long as you have a source time zone, target time zone and tzdata you can convert any time accounting for all the particularities of any particular zone.
  - iso1631 1y ago
    ISO 8601 timezone only allows an offset. You can't encode "04:00 in Cairo on 13th November 2036" as there's no way to know what UTC offset Cairo will have in October 31st 2036. > 2036-11-13 04:00:00 Africa/Cairo Is fine > 2036-11-13 04:00:00 +0200 Is not, as the rules around moving from +3 to +2 may well have changed by them.
    - seanhunter 1y ago
      That’s got literally nothing to do with ISO 8601 though. Times are just hard and there’s no way to know the future with any kind of certainty. In this case there’s no way of knowing whether Egypt will by 2036 have changed their timezone or added or eliminated DST. Nothing to do with ISO 8601, just the world is uncertain. Take the UK for another example. The daylight savings dates are actually set by act of parliament. Although they always have fallen in the pattern that everyone knows, for dates in future years beyond the ones they have already set, they could hypothetically (if you want to be literal-minded about it) change the law to make DST happen on absolutely any day of the year or not at all.
      - iso1631 1y ago
        ISO 8601 only allows timezones as offsets, not as locations. If it allowed "Africa/Cairo" instead of "+0200" that would be fine. > they could hypothetically (if you want to be literal-minded about it) change the law to make DST happen on absolutely any day of the year or not at all. That's the whole point - that's why you store future date/times with the location, not the offset, and not in UTC
        phiresky 1y ago
        There's an extension to ISO8601 that fixes this and is starting to become supported in libraries: 2019-12-23T12:00:00-02:00[America/Sao_Paulo] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal/ZonedDateTime#rfc_9557_format https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
      - jrochkind1 1y ago
- badestrand 1y ago
  This has nothing to with the dates being in the future and only with convention and labeling the field correctly. And in the table example you don't need the "where", because it's obviously in the restaurant's timezone.
  - jrochkind1 1y ago
    If I want to book an appointment for April 12th 2027 at 2:00pm, then that's the time I want. If my locale decides in 2026 to opt out of daylight savings time and not use it anymore -- it does not mean my appointment is now at 1:00pm instead. My appointment is still at April 12th 2027 at 2:00pm. But if I had saved it as a prediction of a UTC time in ISO 8601, then the system would think my appointment was now at 1:00pm. This is why it has to do with dates being in the future. A past date-time can be converted to a UTC time represneted in ISO8601 that will not ever change (if it was converted properly). I'm not sure where you got restaurants from -- you are the first person in this thread to mention restaurants? That is one use case for storing dates and times in the future, but certainly not the only one! There are of course some where the time zone is not "obvious". You realize there is software that's used for things other than restaurant orders and reservations, right? (Also I can imagine a restaurant that's a mobile food truck in an area near a timezone border...) You speak very authoritatively and combatively about something I think you may not be on the same page about.
    - mattmanser 1y ago
      I did mention booking a table, because I used to work with restaurant booking. It is eye-opening to have not one but two devs challenge me, both seasoned accounts so probably experienced developers. But I've dealt with the real problems it causes and they clearly have never touched future dates or they'd have already hit these problems. Or maybe the US's timezones are more stable than the EU's? I think between the two startups they had something like 2 million uniques a year, with bookings in the 100,000s, so not exactly huge scale either. And only operated in like 4 countries. But we still hit them.

rendaw 1y ago

And what format does work for future dates? Or do you mean that ISO 8601 doesn't work but RFC 3339 does work or some other updated ISO/RFC format?

mattmanser 1y ago
I'm not dealing with it anymore, I was when I worked in a couple of restaurant focused SaSSes. Someone else has mentioned RFC 9557. So you might be able to deal with it with 8601 for past dates and 9557 for future.

mattmanser 1y ago

Timezones change, more frequently than you realize. Some countries even used to change when summer time started regularly. It's got better than it used to be afaik. Also you need to take into account where the user is going to be. With future dates, time is relative. So at the very least you often need the time + the timezone of the location. Book me a table at 8, means book me a table in Berlin time at 8, not in San Francisco time at 8. Same with displaying future dates, you need the context of where.

Philip-J-Fry 1y ago
This is nothing to do with ISO 8601 though. You can represent time zones with that format. So long as you have a source time zone, target time zone and tzdata you can convert any time accounting for all the particularities of any particular zone.
- iso1631 1y ago
  ISO 8601 timezone only allows an offset. You can't encode "04:00 in Cairo on 13th November 2036" as there's no way to know what UTC offset Cairo will have in October 31st 2036. > 2036-11-13 04:00:00 Africa/Cairo Is fine > 2036-11-13 04:00:00 +0200 Is not, as the rules around moving from +3 to +2 may well have changed by them.
  - seanhunter 1y ago
    That’s got literally nothing to do with ISO 8601 though. Times are just hard and there’s no way to know the future with any kind of certainty. In this case there’s no way of knowing whether Egypt will by 2036 have changed their timezone or added or eliminated DST. Nothing to do with ISO 8601, just the world is uncertain. Take the UK for another example. The daylight savings dates are actually set by act of parliament. Although they always have fallen in the pattern that everyone knows, for dates in future years beyond the ones they have already set, they could hypothetically (if you want to be literal-minded about it) change the law to make DST happen on absolutely any day of the year or not at all.
    - iso1631 1y ago
      ISO 8601 only allows timezones as offsets, not as locations. If it allowed "Africa/Cairo" instead of "+0200" that would be fine. > they could hypothetically (if you want to be literal-minded about it) change the law to make DST happen on absolutely any day of the year or not at all. That's the whole point - that's why you store future date/times with the location, not the offset, and not in UTC
      - phiresky 1y ago
        There's an extension to ISO8601 that fixes this and is starting to become supported in libraries: 2019-12-23T12:00:00-02:00[America/Sao_Paulo] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal/ZonedDateTime#rfc_9557_format https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
    - jrochkind1 1y ago
badestrand 1y ago
This has nothing to with the dates being in the future and only with convention and labeling the field correctly. And in the table example you don't need the "where", because it's obviously in the restaurant's timezone.
- jrochkind1 1y ago
  If I want to book an appointment for April 12th 2027 at 2:00pm, then that's the time I want. If my locale decides in 2026 to opt out of daylight savings time and not use it anymore -- it does not mean my appointment is now at 1:00pm instead. My appointment is still at April 12th 2027 at 2:00pm. But if I had saved it as a prediction of a UTC time in ISO 8601, then the system would think my appointment was now at 1:00pm. This is why it has to do with dates being in the future. A past date-time can be converted to a UTC time represneted in ISO8601 that will not ever change (if it was converted properly). I'm not sure where you got restaurants from -- you are the first person in this thread to mention restaurants? That is one use case for storing dates and times in the future, but certainly not the only one! There are of course some where the time zone is not "obvious". You realize there is software that's used for things other than restaurant orders and reservations, right? (Also I can imagine a restaurant that's a mobile food truck in an area near a timezone border...) You speak very authoritatively and combatively about something I think you may not be on the same page about.
  - mattmanser 1y ago
    I did mention booking a table, because I used to work with restaurant booking. It is eye-opening to have not one but two devs challenge me, both seasoned accounts so probably experienced developers. But I've dealt with the real problems it causes and they clearly have never touched future dates or they'd have already hit these problems. Or maybe the US's timezones are more stable than the EU's? I think between the two startups they had something like 2 million uniques a year, with bookings in the 100,000s, so not exactly huge scale either. And only operated in like 4 countries. But we still hit them.