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

61–70 of 177 posts

Re: RFC 3339 vs. ISO 8601

#61

Post by throwaway09223 »

kstenerud wrote: post #54
throwaway09223 wrote: post #50

Earlier quoted context omitted.

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 bu…

The special representation isn't TAI (seconds from epoch), the complex and special representations are the human readable formats. It's the human formats that incorporate intractable aspects of solar mechanics, law, and geography. TAI is the simple answer here.

It looks like you have a human readable (CTE) and binary format (CBE), and you use human-style formatting for the computer readable binary format. This seems incongruous to say the least, especially when I look at how you're representing other numeric types.

While human readable formats are complex, there are standard functions which generate them from epoch time. It's trivial to do this in a display layer, and strongly recommended architecturally speaking.

Also, leap seconds do go away if you use TAI. That's the entire point of TAI. Leap seconds are a display layer issue, just like time zones. They can be applied when translating an epoch to a localized format.

You cannot have seconds-level granularity with the way you've designed your time format. Sorry, but this is just a fact.

Re: RFC 3339 vs. ISO 8601

#62

Post by kortex »

kstenerud wrote: post #51
kortex wrote: post #49

Earlier quoted context omitted.

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.

Nice, that's the parsimonious way to handle it.

I'm really digging this system in general. I hope it gets more traction.

Re: RFC 3339 vs. ISO 8601

#63

Post by marcosdumay »

letmeinhere wrote: post #39
Arcorann wrote: post #21

Earlier quoted context omitted.

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…

ISO business model is so strange; in order to make money they have to hide the actual standard from the vast majority of engineers that it relates to, so we just assume whatever was proposed was close enough.

Yes, on practice the draft becomes the actual standard.

That is, unless it's in a regulated industry that is required by law to follow the actual standard. Then it disobeys the law most of the time, and "disobey" the market the rest of the time and everything breaks. Also, it leaves the people with a secret law that nobody can know the consequences.

The ISO governance should be changed ASAP. It was never good, and nowadays it's a disaster.

Re: RFC 3339 vs. ISO 8601

#64

Post by marcosdumay »

ethbr0 wrote: post #53
colejohnson66 wrote: post #41

Earlier quoted context omitted.

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.

ISO shouldn't sell anything. It doesn't have a profit motive and can be financed by governments without any problem.

Re: RFC 3339 vs. ISO 8601

#65

Post by marcosdumay »

dotancohen wrote: post #35
iwwr wrote: post #30

Earlier quoted context omitted.

Quarter depends on reporting periods, or fiscal year, which does not match calendar year everywhere.

> which does not match calendar year everywhere Yes, this is the reason that ISO-8601 ranges are not sufficient and a Quarter indicator is necessary.

The problem is that if you carry the string '2021-Q1' across countries borders, the days it represents change. That makes for a very bad time interchange format.

I agree that this feature makes quarter indicator necessary. But it also makes it required that the string is something more complex.

Re: RFC 3339 vs. ISO 8601

#66

Post by goldenkey »

cmclaren wrote: post #36
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.

ISO 8601-2:2019 defines quarters in section 4.8, "Sub-year groupings". Your example of "2021-Q1" can be represented as "2021-33".

Where's the 33 come from?

Re: RFC 3339 vs. ISO 8601

#67

Post by computerfriend »

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.

If your birthday party is 2022-05-01T16:00 Asia/Eastern_Siberia but you said 2022-05-01T16:00+1000 instead, then you made a mistake.

If it's really at 2022-05-01T16:00+1000, then it doesn't matter what DST policy changes occur.

Re: RFC 3339 vs. ISO 8601

#68

Post by dmurray »

kortex wrote: post #62
kstenerud wrote: post #51

Earlier quoted context omitted.

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.

Nice, that's the parsimonious way to handle it. I'm really digging this system in general. I hope it gets more traction.

On the other hand, valid data may now be unreasonably long. What if someone gives you a string that starts with 10^12 leading zeros?

Re: RFC 3339 vs. ISO 8601

#69

Post by kps »

superjan wrote: post #60
colejohnson66 wrote: post #41

Earlier quoted context omitted.

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?

For the ‘ISO’ standards where I'm aware of the process, development was funded by the participants. ISO is just a rent-seeking gatekeeper, like academic publishers.

Re: RFC 3339 vs. ISO 8601

#70

Post by kstenerud »

throwaway09223 wrote: post #61
kstenerud wrote: post #54

Earlier quoted context omitted.

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 bu…

The special representation isn't TAI (seconds from epoch), the complex and special representations are the human readable formats. It's the human formats that incorporate intractable aspects of solar mechanics, law, and geography. TAI is the simple answer here. It looks like you have a human readable (CTE) and binary format (CBE), and you use human-style formatting for the computer readable binary format. This seems…

Yes, the "simpler" representation is TAI, but we still live in a human world, and with humans entering and reading the data we must conform to their ways in some things.

The binary and text encodings both store in Gregorian so that codecs don't have the added responsibility of converting between representations (keeps the implementations simple).

TAI is like lye: useful, but not meant to be handled by humans. And since this format is designed for human usability, human time wins the day.

Post reply on HN