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

51–60 of 177 posts

Re: RFC 3339 vs. ISO 8601

#51

Post by kstenerud »

kortex wrote: post #49
kstenerud wrote: post #40

Earlier quoted context omitted.

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

I was going to give you the usual "now there are 15 different standards" but this is actually really well thought out. How does it handle leading zeros in the year, like Long Now likes to do? https://blog.longnow.org/02013/12/31/long-now-years-five-dig...

For the text variant, it just parses the year field as an integer, so leading zeroes would generate the same year value as if you'd omitted them.

Re: RFC 3339 vs. ISO 8601

#52

Post by concordDance »

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…

> 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

Yes, and? The draft standard is the pretty much everyone actually uses. For most purposes it's the "real" one.

Re: RFC 3339 vs. ISO 8601

#53

Post by ethbr0 »

colejohnson66 wrote: post #41
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…

Tangent: what’s the point of these “international standards” when I have to pay to know the standard I’m following? Sure, I can use final drafts, but I shouldn’t have to. It honestly seems like a racket. Businesses collaborate to write a standard that costs hundreds of dollars, and then brand new small businesses can’t afford to assert that they follow them.

If they just sold test validators and certification services instead ("Certified by ISO"), it'd be such a healthier dynamic.

Re: RFC 3339 vs. ISO 8601

#54

Post by kstenerud »

throwaway09223 wrote: post #50
kstenerud wrote: post #40

Earlier quoted context omitted.

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

What's wrong with TAI? Using a date format for precise time types doesn't make much sense because human readable date formats are inherently tied to orbital mechanics[1] (days) and social constructs (timezones, calendars, laws, etc). Better to just record seconds from an epoch. I see you mention leap seconds in your specification, but you don't address how to handle time in the future given that leap seconds can't be…

There are a few reasons:

- The text format is designed for human reading and input. Nobody is going to understand TAI, or bother to look it up. They're going to enter time like they see on their clock.

- Special time representations like TAI require a bunch of complicated machinery to convert to/from a human-friendly format. It's complicated, requires regular maintenance, and implementations have varying levels of buggy. Keeping it human-friendly in the first place eliminates this whole class of problems.

- Leap seconds are already a thing because of the above two reasons, and they're not going away since we're not going to change humanity's understanding of time to something more precise.

We're perfectly capable of handling future dates beyond 6 months without using TAI (and keeping our clocks in sync well enough to be on time).

Re: RFC 3339 vs. ISO 8601

#55

Post by ethbr0 »

sltkr wrote: post #43
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.

You're conflating two separate use cases. The point of the numerical-offset notation is exactly to denote a fixed point in time. For the birthday party example: it's not a given that I want to reschedule it when the local time zone changes (maybe I want to meet before sundown so we can sit outside? in that case, I would want to adjust the local time, keeping the solar timethe same). Sometimes of course, it is desirab…

Exactly. (Fixed objective time) -> (current subjective time) is a problem with enough nuances that you probably don't want your format making assumptions for you.

Look up the Japanese calendar, if you want some fun: https://en.m.wikipedia.org/wiki/Date_and_time_notation_in_Ja...

Re: RFC 3339 vs. ISO 8601

#56

Post by 0xbadcafebee »

School-Cotton wrote: post #47
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.

That’s still ambiguous, since the government might only abolish DST for part of Asia/Eastern_Siberia, causing the zone to split.

I guess we could just put the lat/long and let people figure it out? But that still doesn't fix the time when the time zone does change... So using UTC is a simple fix

Re: RFC 3339 vs. ISO 8601

#57

Post by ethbr0 »

amelius wrote: post #34
cmclaren wrote: post #18

Earlier quoted context omitted.

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.

> Once our species has achieved interstellar travel, we'll probably use a completely different representation for time.

All experience thus far suggests "No." We'll be using all of these formats, plus some new ones.

Re: RFC 3339 vs. ISO 8601

#58

Post by kortex »

pletnes wrote: post #4

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

I use 2021-10-24T10_45_32_123456. Never had to store non-UTC so I'm not sure how I'd notate that. I don't use dots for fractional seconds because while that shouldn't get interpreted as an extension, some systems still do.

Re: RFC 3339 vs. ISO 8601

#59

Post by rogerbinns »

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

NTFS can't have colons in filenames because they are used to name alternate data streams.

https://docs.microsoft.com/en-us/sysinternals/downloads/stre...

Re: RFC 3339 vs. ISO 8601

#60

Post by superjan »

colejohnson66 wrote: post #41
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…

Tangent: what’s the point of these “international standards” when I have to pay to know the standard I’m following? Sure, I can use final drafts, but I shouldn’t have to. It honestly seems like a racket. Businesses collaborate to write a standard that costs hundreds of dollars, and then brand new small businesses can’t afford to assert that they follow them.

It is great when standards become free, but then we need to agree how else to fund the standardization process. Taxpayer money?
Post reply on HN