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

41–50 of 177 posts

Re: RFC 3339 vs. ISO 8601

#41

Post by colejohnson66 »

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.

Re: RFC 3339 vs. ISO 8601

#42

Post by pdw »

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.

Some musea need more than 4 digits to describe their collection...

Re: RFC 3339 vs. ISO 8601

#43

Post by sltkr »

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 desirable (think of the opening hours of a shop, for example), but that's a separate use case.

Similarly with online events involving international guests: if you move an event to keep the local time unchanged, this change might create conflicts on other people's calendars. It's not necessarily the desired outcome.

Another problem with including a time zone name is that not everybody has the same version of the time zone database. At worst, that means that different people will have different interpretations of which point in time is being described. At best, the result will only be eventually consistent.

Re: RFC 3339 vs. ISO 8601

#44

Post by [deleted] »

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.

[deleted]

Re: RFC 3339 vs. ISO 8601

#45

Post by amelius »

pdw wrote: post #42
amelius wrote: post #34

Earlier quoted context omitted.

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.

Some musea need more than 4 digits to describe their collection...

Yeah, but they also need a minus sign.

Re: RFC 3339 vs. ISO 8601

#47

Post by School-Cotton »

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.

Re: RFC 3339 vs. ISO 8601

#48

Post by willis936 »

fanf2 wrote: post #10
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.

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.

Timestamps with a timezone are in UTC.

Re: RFC 3339 vs. ISO 8601

#49

Post by kortex »

kstenerud wrote: post #40
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).

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

Re: RFC 3339 vs. ISO 8601

#50

Post by throwaway09223 »

kstenerud wrote: post #40
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).

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 predicted more than 6mo in advance. This is a key feature of TAI -- no synchronization to earth's orbital mechanics. No leap seconds to keep the sun overhead at noon. This means your time spec will likely be off by seconds when using dates more than 6mo out. It seems like your format is also only useful for recording past dates.

[1] TAI is still tied to earth's frame of reference, of course. At some point when we get more serious about space, timestamps will need to include location and velocity. This is already a problem even on the scale of earth satellites and I don't think anyone's yet created a standard.

Post reply on HN