Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RFC 3339 vs. ISO 8601

ijmacd.github.io

Post reply on HN
Print view View original

31–40 of 177 posts

Re: RFC 3339 vs. ISO 8601

#31

Post by bla3 »

rdpintqogeogsaa wrote: post #27
bla3 wrote: post #24

https://datatracker.ietf.org/doc/html/rfc3339 says that rfc339 is a"profile of iso8601" -- shouldn't it be a true subset? Also, I read through that RFC several times and didn't find where it allows replacing 'Z' with space. Can anyone else find it?

Section 5.6: > NOTE: ISO 8601 defines date and time separated by "T". Applications using this syntax may choose, for the sake of readability, to specify a full-date and full-time separated by (say) a space character.

Thanks!

Seems to contradict sections 5.2 and 5.5 in spirit...

Re: RFC 3339 vs. ISO 8601

#33

Post by fanf2 »

boondaburrah wrote: post #26
LinAGKar wrote: post #19

Earlier quoted context omitted.

By "several filesystems", you mean Windows? NTFS can handle it, but Windows can't (presumably due to using it for drive letters).

':' was the traditional directory separator on Macintosh systems before OSX, therefore it can't be used on HFS+ either. I remember there being some FS funk when OSX came out since it was very common for people to put dates in their filenames using slashes, and well, UNIX doesn't like that. I don't know what APFS does.

As I understand it, : and / get swapped depending on whether you use unix APIs (/ is a directory separator, : is plain) or mac APIs (: is a directory separator and / is plain)

Re: RFC 3339 vs. ISO 8601

#34

Post by amelius »

cmclaren wrote: post #18
TacticalCoder wrote: post #5

I never really thought about six-digits years (I don't really understand what is meant by "by mutual agreement"): is this something in use today and by whom? Who needs six-digits years and only six digit years? I mean: if you're projecting stuff in the future (like, say, continental drift), you'll be stuff at year 99999 and have the exact same problem of wrapping around back to zero when you'd need year 1000000 no? O…

The spec permits more than 4 digits for 'year' by mutual agreement. This is called 'expanded representation'. There is no limit to the number of digits, but parties need to agree on how many additional digits will be used to avoid ambiguous representations. Consider that +002021001 could represent: a) "Oct 1, 202" as a calendar date (proleptic Gregorian), in 'basic' format (i.e. no "-" separator), 5 digits for year.…

I wonder how useful more than 4 digits would be. Once our species has achieved interstellar travel, we'll probably use a completely different representation for time.

Re: RFC 3339 vs. ISO 8601

#35

Post by dotancohen »

iwwr wrote: post #30
venthur wrote: post #28

I'm surprised that neither of them has standardized the quarter, i.e. 2021-Q1. This is fairly common in business.

Quarter depends on reporting periods, or fiscal year, which does not match calendar year everywhere.

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

Re: RFC 3339 vs. ISO 8601

#36

Post by cmclaren »

venthur wrote: post #28

I'm surprised that neither of them has standardized the quarter, i.e. 2021-Q1. This is fairly common in business.

ISO 8601-2:2019 defines quarters in section 4.8, "Sub-year groupings". Your example of "2021-Q1" can be represented as "2021-33".

Re: RFC 3339 vs. ISO 8601

#37

Post by gorgoiler »

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

Re: RFC 3339 vs. ISO 8601

#39

Post by letmeinhere »

Arcorann wrote: post #21
em500 wrote: post #7

This is very neat, but maybe not completely accurate. "2021-10-24 11:02:03Z" is outside iso8601 in the figure, but I think it's valid iso8601. True, "T" is the One True date-time separator in iso8601 (IMO its biggest wart, as it looks awful for human eyes: "2021-10-24T11:02:03Z"). But according to the draft standard[1], page 21: > By mutual agreement of the partners in information interchange, the character [T] may b…

There are some non-trivial changes between the draft standards and the final ISO 8601:2019-1 standard, one of which relates to making the use of T stricter, and the mentioned provision was removed. Regardless, ISO 8601 has generally discouraged using spaces within expressions. From ISO 8601:2004, section 3.4.1: > Unless explicitly allowed by this International Standard the character "space" shall not be used in the r…

ISO business model is so strange; in order to make money they have to hide the actual standard from the vast majority of engineers that it relates to, so we just assume whatever was proposed was close enough.

Re: RFC 3339 vs. ISO 8601

#40

Post by kstenerud »

gorgoiler wrote: post #37

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

This is the biggest reason why I had to develop a new time format for Concise Encoding :/

https://github.com/kstenerud/concise-encoding/blob/master/ce...

https://github.com/kstenerud/concise-encoding/blob/master/ct...

ISO 8601 and RFC 3339 are only useful for times in the past (which works fine for most internet protocols because they're only interested in recording events).

Post reply on HN