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…
RFC 3339 vs. ISO 8601
91–100 of 177 posts
Re: RFC 3339 vs. ISO 8601
#92This 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.
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
#93Earlier 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?
Re: RFC 3339 vs. ISO 8601
#94Earlier 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.
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
#95Earlier 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)
Re: RFC 3339 vs. ISO 8601
#96Re: RFC 3339 vs. ISO 8601
#97Earlier 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.
Re: RFC 3339 vs. ISO 8601
#98Earlier 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?
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
#99Earlier 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.
Re: RFC 3339 vs. ISO 8601
#100Earlier 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.