Live data from Hacker News

RFC 3339 vs. ISO 8601

ijmacd.github.io

91–100 of 177 posts

Re: RFC 3339 vs. ISO 8601

#91

Earlier quoted context omitted.

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

Yup, I wonder if an issuing group pays a fee on new versions as well as a maintenance fee would work out.

Re: RFC 3339 vs. ISO 8601

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

There is a cost to make a standard. Somehow that needs to be paid.

Though iso isn't really spending its own money from what I can tell, so I don't see where their costs are coming from.

Re: RFC 3339 vs. ISO 8601

#93

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?

As I have encountered it, the vast cost of the standardization process is already borne outside of ISO because creation and update of the standards is done by outside participants. Hosting the standards documents is a minuscule cost and fees seems mostly a holdover when potentially large bound physical document publishing and distribution was involved.

Re: RFC 3339 vs. ISO 8601

#94
post #92

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.

There is a cost to make a standard. Somehow that needs to be paid. Though iso isn't really spending its own money from what I can tell, so I don't see where their costs are coming from.

That’s what I’m getting at. The committees are generally funded by big companies who basically sign the rights over to ISO. ISO then charges you hundreds of dollars for a single PDF of a standard (which may contain over a dozen).

It reminds me of scientific journals that do nothing but charge money for other people’s work. It reeks of rent seeking.

Re: RFC 3339 vs. ISO 8601

#95
post #33

Earlier quoted context omitted.

':' was the traditional directory separator on Macintosh systems before OSX, therefore it can't be used on HFS+ either. I remember there being some FS funk when OSX came out since it was very common for people to put dates in their filenames using slashes, and well, UNIX doesn't like that. I don't know what APFS does.

As I understand it, : and / get swapped depending on whether you use unix APIs (/ is a directory separator, : is plain) or mac APIs (: is a directory separator and / is plain)

From what I recall (had a macbook years ago) I could put colons in filenames in the terminal, but not in finder.

Re: RFC 3339 vs. ISO 8601

#97
post #57
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.

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

What date formats from 8000 years ago are still in use?

Re: RFC 3339 vs. ISO 8601

#98

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?

There's a parallel dysfunction in California, where the legally-enforced version of the electrical code is available on paper only, at a price of $224:

https://catalog.nfpa.org/NFPA-70-National-Electrical-Code-wi...

In democracies it seems taxpayer money can only be had for purposes that please some fraction of the legislators.

Re: RFC 3339 vs. ISO 8601

#99
post #34

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.

https://news.ycombinator.com/item?id=24453612

Re: RFC 3339 vs. ISO 8601

#100
post #90

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 Yes, and? The draft standard is the pretty much everyone actually uses. For most purposes it's the "real" one.

Robustness principle. There's no way you should be relying upon a draft to emit things that violate the real standard.

[deleted]
Post reply on HN