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

151–160 of 177 posts

Re: RFC 3339 vs. ISO 8601

#151

Post by kstenerud »

CameronNemo wrote: post #130
kstenerud wrote: post #70

Earlier quoted context omitted.

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.

What's stopping me is that time conversion is complex and incredibly difficult to get right. In order for a format to be successful, it must be usable on all platforms big and small, and across all programming languages. The more complex the task of implementing the format, the less likely it is to be successful.

TAI conversions are not equally available or of the same quality on all platforms and technologies, whereas Gregorian time is available pretty much everywhere and is well tested, robust, and easy to use (relatively speaking. Time is never easy).

If it turns out in future that I've made a serious blunder with this policy, I could just add a new type "TAI time" and bump the Concise Encoding spec version (Concise Encoding documents all specify which version of the spec they adhere to). There are still about 30 or so RESERVED type slots in the binary spec so we're not about to run out. We then get the type, just a little late. The alternative is that I make the format needlessly complicated by pre-emptively adding TAI, and risk destroying its adoption. Being right doesn't mean success...

Re: RFC 3339 vs. ISO 8601

#152

Post by saghm »

eli wrote: post #145
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…

It should not be legal to incorporate proprietary standards into law.

At least in the US, it's fairly hard to outlaw changing laws in certain ways since the people with the power to pass new laws are equally able to change past ones, including the ones that limit their power. The way to do something like this would be to put it in the Constitution, which isn't able to be changed through legislation alone, but it seems that for the time being, adding new amendments isn't really something we're doing as a country.

Re: RFC 3339 vs. ISO 8601

#153

Post by bmn__ »

jrochkind1 wrote: post #139
dv_dt wrote: post #93

Earlier quoted context omitted.

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.

Where's the money going? ISO staff? Who do what?

ISO holds meetings where member delegates improve the drafts and negotiate the standards to be.

Re: RFC 3339 vs. ISO 8601

#154

Post by watersb »

everybodyknows wrote: post #98
superjan wrote: post #60

Earlier quoted context omitted.

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.

yes. excellent example of a situation almost identical to mandating ISO standards.

Should the Library of Congress nationalize the NPFA?

I got my local library to buy a copy of the National Electrical Code. I can study it... but only at the Reference Desk at the library.

There are some derived texts that are pretty good, that the library will let me have, so long as I renew the checkout, and nobody else wants it.

Hmm.

Re: RFC 3339 vs. ISO 8601

#155

Post by zinekeller »

skissane wrote: post #150
marcosdumay wrote: post #146

Earlier quoted context omitted.

Mandated ISO standards in 1947 was absurd secret law too. Democracy is not that new of a concept. It's just that both regulations were much lighter so much fewer people would be affected, and at that time the world was in an extremely totalitarian mood, divided by two countries that imposed dictatorships wherever they went. But entrepreneurship existed by then just like it does now, and you can bet many people went p…

> Mandated ISO standards in 1947 was absurd secret law too. Democracy is not that new of a concept. In the 1940s, if you wanted to read legislation, there was no downloading it for free off the Internet – either you purchased a printed copy, or found a library that held it – and you may have had to travel some distance to do so, there was no guarantee that your neighbourhood public library did. Most people viewed cha…

Very good summary. While it is true that ISO is stuck in time, at the same time its model weren't out-of-place when it was implemented, similar to how copyright laws now seems weird or plain wrong to many here while a century back (outside US, because theirs was weirder) it was widely accepted to compensate corporations who have took their time to record and stamp those phonographs.

Re: RFC 3339 vs. ISO 8601

#156

Post by franga2000 »

mountainriver wrote: post #142
NelsonMinar wrote: post #83

Note that Python still lacks any way to parse these dates in the standard library. You have to use a third party library to parse them. You might think `datetime.fromisoformat` parsed ISO dates but you'd be wrong; it doesn't support the trailing Z or any other form of timezone information. The docs are clear about this, and the developer discussion I've read basically boils down to "it's too hard to parse ISO dates s…

I’m amazed this is still a problem, it makes it hard to treat python seriously

Python has one of the most exhaustive stdlibs out there. Surely the a handful of useful but trivial missing functions don't make it any less serious than, for example, NodeJS, which barely even has a stdlib.

Re: RFC 3339 vs. ISO 8601

#157

Post by gmac »

Zekio wrote: post #129

I keep hoping the whole world will switch to a single timezone utc, that way so many things would be simpler

Wouldn’t that be optimising for a very small group of coders and unusually-frequent travellers at the expense of everyone else?

Re: RFC 3339 vs. ISO 8601

#158

Post by amenghra »

ethbr0 wrote: post #55
sltkr wrote: post #43

Earlier quoted context omitted.

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

Exactly. (Fixed objective time) -> (current subjective time) is a problem with enough nuances that you probably don't want your format making assumptions for you. Look up the Japanese calendar, if you want some fun: https://en.m.wikipedia.org/wiki/Date_and_time_notation_in_Ja...

Related to Japanese time keeping, https://en.m.wikipedia.org/wiki/Japanese_clock is a fun read!

Re: RFC 3339 vs. ISO 8601

#159

Post by dataflow »

skissane wrote: post #150
marcosdumay wrote: post #146

Earlier quoted context omitted.

Mandated ISO standards in 1947 was absurd secret law too. Democracy is not that new of a concept. It's just that both regulations were much lighter so much fewer people would be affected, and at that time the world was in an extremely totalitarian mood, divided by two countries that imposed dictatorships wherever they went. But entrepreneurship existed by then just like it does now, and you can bet many people went p…

> Mandated ISO standards in 1947 was absurd secret law too. Democracy is not that new of a concept. In the 1940s, if you wanted to read legislation, there was no downloading it for free off the Internet – either you purchased a printed copy, or found a library that held it – and you may have had to travel some distance to do so, there was no guarantee that your neighbourhood public library did. Most people viewed cha…

> the idea that everyone was entitled to a free personal copy of all legislation was not widely accepted

Was the idea that everyone is entitled to a copy of all legislation at cost widely accepted? Or did most people believe the the publisher (or the legislature?) should overcharge them and stand to make a profit off it?

I don't know how much "at cost" would be for ISO, but something tells me it wouldn't be an identical 158 CHF for both PDF and paper.

Re: RFC 3339 vs. ISO 8601

#160

Post by KptMarchewa »

franga2000 wrote: post #156
mountainriver wrote: post #142

Earlier quoted context omitted.

I’m amazed this is still a problem, it makes it hard to treat python seriously

Python has one of the most exhaustive stdlibs out there. Surely the a handful of useful but trivial missing functions don't make it any less serious than, for example, NodeJS, which barely even has a stdlib.

Python also has one of the most outdated and dead libs in stdlib out there.

https://www.python.org/dev/peps/pep-0594/

Post reply on HN