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

121–130 of 177 posts

Re: RFC 3339 vs. ISO 8601

#121

Post by ademarre »

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.

There are very many things I never would have discovered and learned if IETF RFCs were not free. The most useful knowledge I've acquired about building things on the internet came from there.

Industries that are more reliant on ISO or other non-free standards are surely worse off because of it.

Re: RFC 3339 vs. ISO 8601

#122

Post by skissane »

marcosdumay wrote: post #63
letmeinhere wrote: post #39

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…

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

ISO was founded in 1947, and back then very many of its standards were about physical objects – pipe threads, screws, bearings, belts, film, steel, plastic, rubber, textiles, etc – and even today they still have many standards on those kinds of topics. Imagine you are an aerospace engineer in the 1970s, and you need a copy of the new standard ISO 46:1973 (Aircraft — Fuel nozzle grounding plugs and sockets) – if nobody at your work has a copy, you just order it and pay for it with the company's money (expense it, get your boss to sign the purchase order, whatever). Nobody would have a problem with that and you wouldn't think there was anything inappropriate about it either, it would just seem totally normal to anybody in the 1970s.

The problem is that technology and culture have changed and ISO hasn't kept up – especially for software-related standards. We are an industry in which there are lots of independent contractors and self-employed people and small businesses, it is easy to be self-taught, in which multi-billion dollar companies will charge millions for software packages and then include in their code some open source library that someone maintains as an unpaid hobby, in which many employers baulk at paying for things which in prior decades employers would have just paid for without question. The culture has changed from one in which people are used to paying money for physical books in person or via mail order, to one in which they expect to get information from the Internet instantaneously and for free.

And it is probably mostly in software that people complain about this. I could be wrong, but I would guess that for aerospace engineers it is no more an issue today than in the 1970s. Even if ISO were to charge a few hundred dollars for a standards document, it would still be a lot cheaper than most things aerospace engineers deal with, and your employer will pay for it, who cares. At big firms such as Airbus or Boeing, they probably have some kind of subscription so their engineers just get access to all new ISO standards automatically.

Re: RFC 3339 vs. ISO 8601

#123

Post by zestyping »

Because the digits are of varying widths in the standard Apple system font, the ticking seconds cause the date strings to jiggle back and forth and the table column widths to jiggle as well!

However, you can use CSS to select the fixed-width variant for digits. This is a perfect example of a use case for:

    * {
        font-variant-numeric: tabular-nums;
    }

Re: RFC 3339 vs. ISO 8601

#124

Post by ademarre »

skissane wrote: post #122
marcosdumay wrote: post #63

Earlier quoted context omitted.

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…

> The ISO governance should be changed ASAP. It was never good, and nowadays it's a disaster. ISO was founded in 1947, and back then very many of its standards were about physical objects – pipe threads, screws, bearings, belts, film, steel, plastic, rubber, textiles, etc – and even today they still have many standards on those kinds of topics. Imagine you are an aerospace engineer in the 1970s, and you need a copy o…

> software-related standards. We are an industry in which there are lots of independent contractors and self-employed people and small businesses, it is easy to be self-taught

Consider also the pace of innovation in software and networking—the internet at large. I think it's both a consequence and a cause of the change in culture you described.

Re: RFC 3339 vs. ISO 8601

#125

Post by remram »

naniwaduni wrote: post #86
remram wrote: post #79

Earlier quoted context omitted.

But it overlaps. It's off, but less than 100% off. "2021-Q1" can be a completely different and non-overlapping range between regions, and even between companies in the same region.

2021-10-24 in UTC+14 (Line Islands) and UTC-10 (Hawaii) are, in fact, 100% off.

Yeah the Line Islands are the exception as always.

Re: RFC 3339 vs. ISO 8601

#126

Post by uwu »

Dunedan wrote: post #107
pletnes wrote: post #4

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

Fun fact: If you download a file containing colons with popular web browsers, they'll try to be helpful and will replace the colons to avoid problems storing the file on filesystems which don't support colons. Took me a while to figure out why the browsers messed with the file names.

chrome's extension api for downloads has the same limitation

filenames that are reserved names on windows (like NUL) or contain characters that are reserved on windows are refused with "Invalid filename", even on platforms and filesystems that don't have the same limitations

this might be desirable for enforcing portability in extensions, but the thing isn't mentioned in the documentation[1] for the api so you had to know about it beforehand (like most extension devs, probably) or find out the hard way when some of your downloads unexpectedly fail (like me)

i was using it on linux in a personal extension i wrote, and i thought it was silly that i had to add extra code to further sanitize and mangle the filenames for an OS i don't even use

[1] https://developer.chrome.com/docs/extensions/reference/downl...

Re: RFC 3339 vs. ISO 8601

#127

Post by neoeno »

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.

One use: I was teaching some developers COBOL, and I wanted to illustrate for them how the Y2K bug came about.

So I gave them a project to do parsing a file with contemporary dates in. Then towards the end I quietly supplied them with a similar file containing dates from the year 10000+.

Whether or not the devs of years past felt it similarly unlikely that their software would live to the year 2000 as we do the year 10000, I don’t know. But it was a fun exercise!

Re: RFC 3339 vs. ISO 8601

#128

Post by merb »

do you now whats ridiculous? that we germans (and europeans) also use the iso 8601 but it's still allowed to use din 5008 and the european date and time notations... WHY??? it's so stupid to use dd.MM.yyyy, it's worse in every way to yyyy-MM-dd. worse than that the old notation is preferred in most official documents..... WHY....

Re: RFC 3339 vs. ISO 8601

#130

Post by CameronNemo »

kstenerud wrote: post #70
throwaway09223 wrote: post #61

Earlier quoted context omitted.

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

with humans entering and reading the data we must conform to their ways in some things

I don't understand what is stopping you from converting from tai to human readable and vice versa at the form/input and display/output layers, respectively.

Post reply on HN