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

101–110 of 177 posts

Re: RFC 3339 vs. ISO 8601

#101

Post by superjan »

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.

I know they don’t subsidize standard development. But there is still cost for running an organization to manage and coordinate (and maybe translate) what is being standardized over hundreds of topics. Of the 40 million in total income, selling standard documents is 1/4 to 1/3 of their income. You don’t pay for the cost of electronic copies, but for running the organization.

source: https://www.iso.org/files/live/sites/isoorg/files/store/en/P...

Re: RFC 3339 vs. ISO 8601

#102

Post by dwheeler »

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.

ISO doesn't pay to develop standards, they assume others will develop the standards.

Historically, the purpose was to pay for printing & distribution. That makes no sense today, but that was its historical justification.

Re: RFC 3339 vs. ISO 8601

#103

Post by macintux »

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…

Plus the naive date times that seem to pop up by default. Frustrating.

Re: RFC 3339 vs. ISO 8601

#104

Post by Dunedan »

macintux wrote: post #103
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…

Plus the naive date times that seem to pop up by default. Frustrating.

Can you elaborate on this?

Parsing ISO 8601 formatted dates doesn't result in naive Python datetimes:

    >>> datetime.fromisoformat("2021-10-24T20:17:41+02:00")
    datetime.datetime(2021, 10, 24, 20, 17, 41, tzinfo=datetime.timezone(datetime.timedelta(seconds=7200)))

Re: RFC 3339 vs. ISO 8601

#105

Post by venthur »

cmclaren wrote: post #36
venthur wrote: post #28

I'm surprised that neither of them has standardized the quarter, i.e. 2021-Q1. This is fairly common in business.

ISO 8601-2:2019 defines quarters in section 4.8, "Sub-year groupings". Your example of "2021-Q1" can be represented as "2021-33".

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

Re: RFC 3339 vs. ISO 8601

#106

Post by jacobmischka »

remram wrote: post #80
jacobmischka wrote: post #13

I like the concept of ISOs in general, but I personally prefer RFC 3339. The space makes it so much easier to read at a glance, and I can't imagine it makes parsing much different algorithmically?

In what context would you prefer ISO over RFC? The fact that ISO standards cost hundreds to read and apparently change over time, while RFCs are openly available and get replaced if necessary, makes it hard for me to see ISO as more than a crutch. If there's an open standard, I'll use that, and people will actually know what I'm talking about.

I agree with everything you said. I guess I just naively like the idea of an international standards organization in theory, though I suppose that's also essentially what the IETF is too.

Re: RFC 3339 vs. ISO 8601

#107

Post by Dunedan »

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.

Re: RFC 3339 vs. ISO 8601

#108

Post by throwaway09223 »

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…

Well, I guess we'll have to agree to disagree.

When I look at human readable logfiles I see a trend towards using epoch seconds for exactly these reasons. It's so easy to convert, it outweighs the anti-usability aspects inherent in formatted strings. I've converted all my own human readable file formats to epoch times for exactly these reasons and my customers seem to strongly prefer it.

Re: RFC 3339 vs. ISO 8601

#109

Post by NelsonMinar »

Dunedan wrote: post #104
macintux wrote: post #103

Earlier quoted context omitted.

Plus the naive date times that seem to pop up by default. Frustrating.

Can you elaborate on this? Parsing ISO 8601 formatted dates doesn't result in naive Python datetimes: >>> datetime.fromisoformat("2021-10-24T20:17:41+02:00") datetime.datetime(2021, 10, 24, 20, 17, 41, tzinfo=datetime.timezone(datetime.timedelta(seconds=7200)))

Your example demonstrates I'm wrong with isoformat not supporting any timezone info. Sorry about that. Given it can handle +02:00 I wonder why they don't just add support for z and Z and instantly cover 95% of the world's JSON data?

Re: RFC 3339 vs. ISO 8601

#110

Post by ethbr0 »

TheCoelacanth wrote: post #97
ethbr0 wrote: post #57

Earlier quoted context omitted.

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

Solstice and equinox-relative seasons?
Post reply on HN