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

11–20 of 177 posts

Re: RFC 3339 vs. ISO 8601

#11

Post by gerikson »

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…

I've seen 5 digit years in use online in some places, but not 6-digit (so far). Maybe it's influenced by the Long Now project?

For long timescales (geological deep time) I believe using SI units are more appropriate: https://en.wikipedia.org/wiki/Year#SI_prefix_multipliers

Re: RFC 3339 vs. ISO 8601

#12

Post by [deleted] »

drdec wrote: post #9
gerikson wrote: post #3

Earlier quoted context omitted.

It's only needed for disambiguation. That said, I wish the page had actually taken the local time into account. As in your case the times on the page are in my current timezone (CEST) so the "Z", "00:00", "+00:00" is basically just decoration. ~~Even worse, in the intersection we have formats like %h:%m:%s+Z and %h:%m:%s+02:00 that show the same time simultaneously.~~ Edit: it is correct now.

I'm in the America/New_York zone and I see the proper times for the values with "Z" vs the values with "-4:00". That is, they are off by four hours.

[deleted]

Re: RFC 3339 vs. ISO 8601

#14

Post by jacobmischka »

dvh wrote: post #6
pletnes wrote: post #4

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

Me too, I'm usually using 2021-10-24--13-07-59

I use `--` to represent an en dash for date ranges (some_report_2021-01-01--2021-12-31). I don't use times nearly as often, but I separate date from time using an underscore in those instances.

Re: RFC 3339 vs. ISO 8601

#15

Post by lborsato »

drdec wrote: post #9
gerikson wrote: post #3

Earlier quoted context omitted.

It's only needed for disambiguation. That said, I wish the page had actually taken the local time into account. As in your case the times on the page are in my current timezone (CEST) so the "Z", "00:00", "+00:00" is basically just decoration. ~~Even worse, in the intersection we have formats like %h:%m:%s+Z and %h:%m:%s+02:00 that show the same time simultaneously.~~ Edit: it is correct now.

I'm in the America/New_York zone and I see the proper times for the values with "Z" vs the values with "-4:00". That is, they are off by four hours.

I’m in America/New_York as well and I see them correctly. I think your computer’s time zone may be incorrect.

Re: RFC 3339 vs. ISO 8601

#16

Post by rdpintqogeogsaa »

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.

Re: RFC 3339 vs. ISO 8601

#17

Post by LinAGKar »

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…

So that should also be in the dashed circle.

Re: RFC 3339 vs. ISO 8601

#18

Post by cmclaren »

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.

b) "Jan 1, 2021" as an ordinal date, 'basic' format (i.e. no "-" separator), 6 digits for year.

Re: RFC 3339 vs. ISO 8601

#19

Post by LinAGKar »

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

Re: RFC 3339 vs. ISO 8601

#20

Post by smitty1e »

jacobmischka wrote: post #13

I 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?

Space characters affect processing in shell scripts, so one manages them closely, along with colons, as noted elewhere.
Post reply on HN