As someone who frequently works with datetime data, I always felt that in the format YYYY-MM-DDTHH:mm±ZZ:ZZ, it should read "this local time plus the timezone offset gives you utc", not " utc plus the timezone offset gives you this local time", so basically invert the signal from how it is now.
RFC 3339 vs. ISO 8601
71–80 of 177 posts
Re: RFC 3339 vs. ISO 8601
#72As someone who frequently works with datetime data, I always felt that in the format YYYY-MM-DDTHH:mm±ZZ:ZZ, it should read "this local time plus the timezone offset gives you utc", not " utc plus the timezone offset gives you this local time", so basically invert the signal from how it is now.
But then they wouldn't be lexicographically sortable.
Re: RFC 3339 vs. ISO 8601
#73Earlier quoted context omitted.
Nice, that's the parsimonious way to handle it. I'm really digging this system in general. I hope it gets more traction.
On the other hand, valid data may now be unreasonably long. What if someone gives you a string that starts with 10^12 leading zeros?
This is where security and limits comes in:
https://github.com/kstenerud/concise-encoding/blob/master/ce...
Re: RFC 3339 vs. ISO 8601
#74Earlier quoted context omitted.
Some musea need more than 4 digits to describe their collection...
Yeah, but they also need a minus sign.
By default, ISO 8601-1:2019 does not permit negative years in date representations.
Expanded representation (i.e. five digits or more for the year) permits both positive and negative years (and the sign is mandatory for both positive and negative years).
ISO 8601-2:2019 has provisions for numeric extensions. Subclause 4.4.1.2 permits negative four-digit years (years -9999 to -0001).
Note that both of these options require mutual agreement.
Re: RFC 3339 vs. ISO 8601
#75The use of colon in timestamps is incompatible with several filesystems and this just drives me nuts.
I just wish there was proper support and UX for dates on file systems, so I can actually properly search for date ranges instead of having "iso8601 sorts lexicographically!" as a crutch used within filenames.
Re: RFC 3339 vs. ISO 8601
#76Earlier quoted context omitted.
> which does not match calendar year everywhere Yes, this is the reason that ISO-8601 ranges are not sufficient and a Quarter indicator is necessary.
The problem is that if you carry the string '2021-Q1' across countries borders, the days it represents change. That makes for a very bad time interchange format. I agree that this feature makes quarter indicator necessary. But it also makes it required that the string is something more complex.
If you carry the string '2021-10-24' across countries borders, the moments in time that it represents change as well.
That makes doesn't make it a bad time interchange format for certain use cases, though. Just like everything else with time, one must be aware of caveats. Those include timezones, leap periods, culture, DST, formats, legislation (modern and ancient), etc.
Re: RFC 3339 vs. ISO 8601
#77Earlier quoted context omitted.
ISO 8601-2:2019 defines quarters in section 4.8, "Sub-year groupings". Your example of "2021-Q1" can be represented as "2021-33".
Where's the 33 come from?
There is a list of "Sub-year groupings" which assign two-digit numbers to seasons (hemisphere independent), seasons (Northern Hemisphere), seasons (Southern Hemisphere), quarters, quadrimesters (four-month periods), and semestrals (six-month periods). The numbering starts at 21.
The numbers 1 to 12 are already used to represent months in formats such as YYYY-MM, so starting this list higher than 12 allows these (certainly rare) representations to coexist. e.g. "2021-12" represents "October, 2021" and "2021-29" represents "Spring, Southern Hemisphere, 2021".
Re: RFC 3339 vs. ISO 8601
#78…and none of these do timezones properly! If your birthday party is: 2022-05-01T16:00+1000 …but tomorrow’s government abolishes daylight savings time, your birthday event has to change to: 2022-05-01T16:00+0900 . If you’d just said: 2022-05-01T16:00 Asia/Eastern_Siberia …you’d be fine and everyone will show up at the right time.
Every year when DST ends, there are two hours during which the locale name based time is not unique since it could be both shortly before or after the time got turned back.
But beside that this would make sense when everyone involoved is living in the same timezone, but when coordinating internationally (which tends to be the main focus when the ISO is involved) we really do not want such changes to happen automatically. Everyone in the local timezone is likely to be aware of time changes so they know they have to adapt, but everyone in another timezone might have almost no way of knowing. For them, an event starting at a different (UTC) time is a rescheduling, no matter if it is caused by some timezone adjustment or not. So hiding this behind some tzdb change instead of sending out new dates would most likely mean that they appear at the wrong time.
Also including offsets ensures that the person writing the time knows the right offset. In the last year, I had quite some meetings where the host wanted to be nice and send the time in the local timezone for every participant. Since only timezone names and no offsets were included and the host mostly assumed that their local DST rules apply globally, this resulted in a giant mess. Especially after people informed them about errors, so the times switched back and forth between times assuming DST or not assuming DST. Without seeing the offset, there was no way of knowing which time was actually intended. If a UTC offset is given, most local people can relatively easily verify that it is the expected offset but even more importantly, you can independently convert it to the right zone no matter what the author thought.
Re: RFC 3339 vs. ISO 8601
#79Earlier quoted context omitted.
The problem is that if you carry the string '2021-Q1' across countries borders, the days it represents change. That makes for a very bad time interchange format. I agree that this feature makes quarter indicator necessary. But it also makes it required that the string is something more complex.
If you carry the string '2021-10-24' across countries borders, the moments in time that it represents change as well. That makes doesn't make it a bad time interchange format for certain use cases, though. Just like everything else with time, one must be aware of caveats. Those include timezones, leap periods, culture, DST, formats, legislation (modern and ancient), etc.
But it overlaps. It's off, but less than 100% off.
"2021-Q1" can be a completely different and non-overlapping range between regions, and even between companies in the same region.
Re: RFC 3339 vs. ISO 8601
#80I like the concept of ISOs in general, but I personally prefer RFC 3339. The space makes it so much easier to read at a glance, and I can't imagine it makes parsing much different algorithmically?
In what context would you prefer ISO over RFC? The fact that ISO standards cost hundreds to read and apparently change over time, while RFCs are openly available and get replaced if necessary, makes it hard for me to see ISO as more than a crutch. If there's an open standard, I'll use that, and people will actually know what I'm talking about.