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

131–140 of 177 posts

Re: RFC 3339 vs. ISO 8601

#131

Post by convolvatron »

mlyle wrote: post #90
concordDance wrote: post #52

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.

there is never any final difference...since you work in a group, and every change is vetted, it only gets ratified when everyone says 'yep, no more changes'

Re: RFC 3339 vs. ISO 8601

#132

Post by tgsovlerkhgsel »

bluGill wrote: post #92
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.

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 seems like a great use for taxes. I suspect the economic benefits from the easy accessibility of the standards (just imagine the cost of the approval processes to buy the standards and handle access, plus the cost of the standards remaining inaccessible to smaller players) would outweigh the financial costs.

Re: RFC 3339 vs. ISO 8601

#133

Post by tgsovlerkhgsel »

The one big failure of RFC 3339 is that it doesn't specify the actual rules for the separator:

    Applications using this syntax may choose, for the sake of
    readability, to specify a full-date and full-time separated by
    (say) a space character.
Is separating it by a tab valid? A tilde? An underscore, as this website shows? Since this is so underspecified, there will be receivers that accept only T, and others that accept the T and some arbitrarily chosen character set. The ABNF only allows T.

I don't know how a standard that was specifically written to resolve the issues resulting from such ambiguities ended up with such a crucial issue.

Re: RFC 3339 vs. ISO 8601

#134

Post by tgsovlerkhgsel »

merb wrote: post #128

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

Because unless you start fining or imprisoning people for using the wrong date format, people don't care what you write in a law book and will continue to use what they're used to if it works well enough.

Allowing DIN 5008 simply acknowledges reality. Not acknowledging reality is a good way to make people decide that whatever is telling them they're doing it wrong is just "ivory tower" nonsense and should all be ignored at best, possibly actively opposed.

Re: RFC 3339 vs. ISO 8601

#135

Post by tgsovlerkhgsel »

cmclaren wrote: post #111
venthur wrote: post #105

Earlier quoted context omitted.

Unfortunately the document is not freely available. Can you elaborate how it works?

The latest standard (2019) is divided into two parts: ISO 8601-1 and ISO 8601-2. Part 2 is titled "Extensions" and includes many different - but optional - ways to extend representations of dates and times. In my opinion, Part 2 represents the "leftovers" - that which was too domain specific or esoteric to warrant broad implementation. Representations of seasons, quarters, etc. is one of many types of extensions incl…

This, in combination with the fact that the lookup table is paywalled, makes it a great competitor for the "extremely pointlessly overengineered standards" award.

I wonder if there is any software that actually supports that.

Re: RFC 3339 vs. ISO 8601

#136

Post by Macha »

ectopod wrote: post #118
Macha wrote: post #8

Earlier quoted context omitted.

If you're looking in the backwards direction and its important what local time in a different location it happened, that's the use case for offset date time. Maybe you're investigating traffic patterns in which case it can be clearer when it's 6pm local time rather than noon utc or whatever. Embedding that in the returned timestamp can save another field. However, for the forward looking/scheduling one one, if you wa…

As far as I know, there isn't an official standard for timezone names so you need to define which set of names you are using.

IANA tzdb is the defacto standard in the software industry.

Re: RFC 3339 vs. ISO 8601

#137

Post by heavenlyblue »

neoeno wrote: post #127
amelius wrote: 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.

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…

Don’t forget that when Y2K problems were being created the hardware was _way_ less performant than the hardware of today. There was a reason to be wary of how much memory you are using, now there isn’t much.

Re: RFC 3339 vs. ISO 8601

#138

Post by benatkin »

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…

Yep.

from dateutil.parser import isoparse

Re: RFC 3339 vs. ISO 8601

#139

Post by jrochkind1 »

dv_dt wrote: post #93
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?

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?

Re: RFC 3339 vs. ISO 8601

#140

Post by erik_seaberg »

LinAGKar wrote: post #19
pletnes wrote: post #4

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

By "several filesystems", you mean Windows? NTFS can handle it, but Windows can't (presumably due to using it for drive letters).

Also HDFS. This bit me the first time I tried to write a Hadoop job that wrote every run to a new output dir.
Post reply on HN