3 ms·

This should be called bad advice about dates every developer should avoid. ISO 8601 does NOT work with future dates. It does not work with cross border appoint

This should be called bad advice about dates every developer should avoid. ISO 8601 does NOT work with future dates. It does not work with cross border appointment booking. ISO 8601 only works for dates and times that have already happened. I have 20 years, have worked with apps that relied on future and past dates, have used date pickers since 2005 and would still hesitate to give advice about what is an incredibly complex problem that entirely depends on your use case.

dotancohen 11mo ago
Tell us more. Please.
Telaneo 11mo ago
> 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 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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
burningChrome 11mo ago
15 years a front-end dev, 5 years as accessibility engineer. Every time someone brings up a date picker I just wanna pull the pin on my parachute and jump out the window. 100% agree, its one of the hardest components to get right for so many different reasons. Like you mentioned in cross border booking, just in Canada they have three or four different ways to write a date. I worked for a healthcare company and just getting a consensus on that alone was a 8 month process of back and forth. I feel your pain man, I really do.

dotancohen 11mo ago

Tell us more. Please.

Telaneo 11mo ago

> 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 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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 11mo 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

burningChrome 11mo ago

15 years a front-end dev, 5 years as accessibility engineer. Every time someone brings up a date picker I just wanna pull the pin on my parachute and jump out the window. 100% agree, its one of the hardest components to get right for so many different reasons. Like you mentioned in cross border booking, just in Canada they have three or four different ways to write a date. I worked for a healthcare company and just getting a consensus on that alone was a 8 month process of back and forth. I feel your pain man, I really do.