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

161–170 of 177 posts

Re: RFC 3339 vs. ISO 8601

#161

Post by GoblinSlayer »

em500 wrote: post #7

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

RFC 3339 is concerned with interoperability problems due to date formats. By adding a space you create interoperability problems. And space-based format uses ' UTC' suffix instead of Z suffix.

Re: RFC 3339 vs. ISO 8601

#162

Post by jrochkind1 »

bmn__ wrote: post #153
jrochkind1 wrote: post #139

Earlier quoted context omitted.

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.

Are some people arguing that doesn't need to happen, or can be done cheaper? Is that argument based on detailed attention to the budget?

Re: RFC 3339 vs. ISO 8601

#163

Post by eli »

saghm wrote: post #152
eli wrote: post #145

Earlier quoted context omitted.

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

To be clear: I'm not requesting any new rights, merely the enforcement of existing legal principles that laws cannot be copyrighted by a private entity and that people have a fundamental right to freely read the laws that bind them.

Carl Malamud has been fighting this point worldwide with some success for decades. For example here's the state or Oregon agreeing: https://public.resource.org/oregon.gov/index.html

Re: RFC 3339 vs. ISO 8601

#164

Post by marcosdumay »

dataflow wrote: post #159
skissane wrote: post #150

Earlier quoted context omitted.

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

Neither. Access to legislation must be possible at no cost for everybody. Otherwise you can't expect people to follow it.

Of course, that doesn't entitle you to a copy, making it available at libraries is already enough.

Re: RFC 3339 vs. ISO 8601

#165

Post by franga2000 »

KptMarchewa wrote: post #160
franga2000 wrote: post #156

Earlier quoted context omitted.

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/

The stdlib contains outdated modules, it's not outdated itself. Windows 11 still contains some DLLs dating back as far as at least NT 4.0 and nobody would call it an outdated OS. The stdlib is constantly being improved and I for one am glad that older and rarely used features are being kept around instead of booting them out with the next minor release.

Re: RFC 3339 vs. ISO 8601

#166

Post by 0xbadcafebee »

ComputerGuru wrote: post #88
0xbadcafebee wrote: post #56

Earlier quoted context omitted.

I guess we could just put the lat/long and let people figure it out? But that still doesn't fix the time when the time zone does change... So using UTC is a simple fix

UTC doesn’t fix anything if you meant 6pm my local time on that day, come hell or high water. Eg: Work at the local library is always 9 to 5 (again “local time”) and you mean precisely one hour after work lets up, regardless of whatever daylight savings or time zone changes occur between now and then. You need to use either a naive date-time representation coupled with the additional context (“my time”) or use someth…

One thing has nothing to do with the other. Timestamps are intended to simply record what the time is in a given place - not to telegraph expectations about local business hours.

China has one official time zone that covers five geographical time zones. Tell me, exactly how does saying "It's 6PM in China" tell me anything useful about the local library? You have to go to a local website and find out what time "in that part of China" the library is open. The timezone was never intended to express that.

Re: RFC 3339 vs. ISO 8601

#167

Post by mountainriver »

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.

I would rather they did less well

Re: RFC 3339 vs. ISO 8601

#168

Post by euroderf »

Arcorann wrote: post #21
em500 wrote: post #7

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

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…

Couldn't they permit "_" in place of "T" ? It's not a space, and it certainly makes a date_time string quicker to parse at a glance.

Re: RFC 3339 vs. ISO 8601

#169

Post by Dunedan »

macintux wrote: post #148
Dunedan wrote: post #104

Earlier quoted context omitted.

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

Sorry, was on mobile and didn't elaborate. Was referring to datetime.datetime.now(); why can't it incorporate the local timezone?

Well, it can, it's just not the default:

    >>> from datetime import datetime, timezone
    >>> datetime.now(tz=timezone.utc).astimezone()
    datetime.datetime(2021, 10, 25, 19, 58, 34, 51668, tzinfo=datetime.timezone(datetime.timedelta(seconds=7200), 'CEST'))
Or if you want to use a specific timezone:

    >>> from datetime import datetime
    >>> from zoneinfo import ZoneInfo
    >>> datetime.now(tz=ZoneInfo("Europe/Berlin"))
    datetime.datetime(2021, 10, 25, 19, 58, 34, 51668, tzinfo=zoneinfo.ZoneInfo(key='Europe/Berlin'))

Re: RFC 3339 vs. ISO 8601

#170

Post by remram »

naniwaduni wrote: post #147
remram wrote: post #125

Earlier quoted context omitted.

Yeah the Line Islands are the exception as always.

We could've gone with most of New Zealand (UTC+13 summer time) and any of the US territories in UTC-11. These are marginal cases, not exceptional ones.

Fine, they overlap with the UTC day. They are less than 100% compared to the UTC day, even if they can be 100% off with each other.
Post reply on HN