RFC 3339 vs. ISO 8601
ijmacd.github.io
RFC 3339 vs. ISO 8601
1–10 of 177 posts
Re: RFC 3339 vs. ISO 8601
#2Is 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.
Re: RFC 3339 vs. ISO 8601
#3Is 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.
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.
Re: RFC 3339 vs. ISO 8601
#4The use of colon in timestamps is incompatible with several filesystems and this just drives me nuts.
Re: RFC 3339 vs. ISO 8601
#5I 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?
Or is it "infinite": as in, the spec allows for 8-digits years, 10, etc.?
Re: RFC 3339 vs. ISO 8601
#6The 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
Re: RFC 3339 vs. ISO 8601
#7This 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 be omitted in applications where there is no risk of confusing a date and time of day representation with others defined in this International Standard
[1] The actual ISO standard is not freely available, but the Library of Congress has free draft standards: https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_i... https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0039_i...
Re: RFC 3339 vs. ISO 8601
#8Is 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.
If you're looking in the backwards direction and its important what local time in a different location it happened, that's the use case for offset date time. Maybe you're investigating traffic patterns in which case it can be clearer when it's 6pm local time rather than noon utc or whatever. Embedding that in the returned timestamp can save another field.
However, for the forward looking/scheduling one one, if you want it to keep the same time across timezone/DST policy changes, you need to the full on timezone designator (i.e. America/New_York), not just the offset or short, ambiguous timezone code (EST).
There's no allowance in ISO 8601 for this, so you need a side channel like another field to communicate this. I've seen other date formats do something like 2021-10-11T12:13:14[America/New_York] to allow for this. Once you do this, it probably makes sense to elide the offset to avoid the risk of consfusing mismatches between it and the timezone.
Re: RFC 3339 vs. ISO 8601
#9Is 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.
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.
Re: RFC 3339 vs. ISO 8601
#10Is 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.
One of the aims of RFC 3339 is to eliminate the ambiguous variants from ISO 8601, so it makes the timezone obligatory. Timestamps without a timezone are in an unspecified local time.