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

21–30 of 177 posts

Re: RFC 3339 vs. ISO 8601

#21

Post by Arcorann »

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

Similarly, from ISO 8601:2019-1, section 3.2.1:

> The character "space" shall not be used in the expressions.

However, through looser interpretation of the standard, "2021-10-24 11:02:03Z" could be allowed if treated as a date representation followed by a space followed by a time representation (note that the formal time representation in ISO 8601:2019-1 is T11:02:03Z, but it allows omission of T for extended format as per 5.3.5).

Re: RFC 3339 vs. ISO 8601

#22

Post by grey_earthling »

rdpintqogeogsaa wrote: post #16
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…

It's correct. Omission means 2021-10-2411:02:03Z, not replacing it with a space instead.

Omitting the hyphens and colons is allowed too (IIRC), so I suppose omitting the T is intended for cases like 20211024110203Z — which IMO is a sensible format when there's no ambiguity that this is a date-time.

Re: RFC 3339 vs. ISO 8601

#23

Post by sanderjd »

willis936 wrote: post #2

Is the timezone necessary to be compliant? My favorite ISO 8601 format is "%Y%M%DT%h%m%s%", but the table includes a "−Z" on the end and the "Now" column evaluates this as my current timezone. It says the list isn't exhaustive, but I'm just curious how often others actually embed the timezone rather than just passing around UTC.

In my view what's best is to always pass around utc but include the Z to make it explicit that's what you're doing. It's a very succinct way to represent that and can be very valuable to disambiguate so I think it's worth the extra character.

Re: RFC 3339 vs. ISO 8601

#25

Post by cmclaren »

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…

Your example is valid in ISO 8601-1:2019.

There are only two possible representations for which "T" is required: hh or hhmm in 'basic' format (i.e. no ":" separator). The former could be confused with a two-digit century, the latter could be confused with a four-digit year. Adding "T" to hh or hhmm solves this.

Any of the following eliminates the "risk of confusion":

  - 'extended' format (hh:mm)
  - decimal fraction (hhmm,m or hh,h; see 5.3.1.4);
  - UTC designator (hhmmZ or hhZ; see 5.3.3), or;
  - time shift (hhmm±hhmm, hhmm±hh, hh±hhmm, or hh±hh; see 5.3.4).
Also worth noting: hhmmss in 'basic' format (i.e. no ":" separator) does not pose a risk of confusion, as YYYYMM in 'basic' format (i.e. no "-" separator) is not permitted by the spec.

Re: RFC 3339 vs. ISO 8601

#26

Post by boondaburrah »

LinAGKar wrote: post #19
pletnes wrote: post #4

The use of colon in timestamps is incompatible with several filesystems and this just drives me nuts.

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.

Re: RFC 3339 vs. ISO 8601

#27

Post by rdpintqogeogsaa »

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.

Re: RFC 3339 vs. ISO 8601

#29

Post by midasuni »

sanderjd wrote: post #23
willis936 wrote: post #2

Is the timezone necessary to be compliant? My favorite ISO 8601 format is "%Y%M%DT%h%m%s%", but the table includes a "−Z" on the end and the "Now" column evaluates this as my current timezone. It says the list isn't exhaustive, but I'm just curious how often others actually embed the timezone rather than just passing around UTC.

In my view what's best is to always pass around utc but include the Z to make it explicit that's what you're doing. It's a very succinct way to represent that and can be very valuable to disambiguate so I think it's worth the extra character.

Sometimes you are defining a date by the local time.

I have a meeting on June 13th 2026 at 15:00 london time.

This could be 2026-06-13 14:00:00 Z

But if the U.K. drops summer time, or makes it double summer time, the meeting will still be 1500 london time, but the UTC time might change to 1500Z or 1300Z

Re: RFC 3339 vs. ISO 8601

#30

Post by iwwr »

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.
Post reply on HN