Judging by the time it takes to completely migrate away from old technologies, I wouldn't be surprised if we will be emulating x86 on our quantum computers in the year 100k.

FTL pod launch rails will be 4 feet 8.5 inches apart.

> ISO 8601 is prolific. Is RFC 3339 well used/adopted in any system?

90% of the time when a library says ISO 8601 it doesn't actually implement the more esoteric parts of ISO 8601.

A self-contained full implementation of ISO 8601 is of dubious value anyway.

Whether time is used for a private application or for a standard, the important part is the agreement on what information is being conveyed and in what format. Receiving just the week of the year when you were expecting a time range is not useful.

Likewise, having some sort of official support for "20" as identifying the century (say via a Century type) is a lot of code to carry around and maintain - especially before there's a business need to represent centuries. You tend to need full date time instants, then maybe dates and times independently, then maybe durations - with only a few applications tending to need things like ranges.

Yeah, this means that when you want to use ranges and choose ISO 8601 as your format, you may not find readily-available, off-the-shelf parsers.

Both Golang (official time package) and Rust (Chrono) have built in tools for dealing with RFC 3339 but not for RFC 8601. IIRC I read about issues with ambiguity in RFC 8601 not present in RFC 3339, and again IIRC Python had issues round-tripping dates because of this.

It's ISO 8601, not RFC 8601 (which is `Message Header Field for Indicating Message Authentication Status`).

In fairness, it's doubtful that either Go's or Rust's time-handling facilities would implement support for an email auth header.

Interesting. This is the first time I'm even hearing of RFC 3339. ISO 8601 is just taken for granted everywhere... languages, tools and services (databases, etc).

Admittedly I've not worked with Golang or Rust, and my Python has been limited to scripting more than developing.

Almost everything that claims to implement ISO 8601 actually implements RFC 3339 instead.

I think a lot of people assume ISO 8601 just means 2023-08-31 / 2023-08-31T14:55:30Z.. if only

I could imagine scientific tooling wanting to represent dates in the far future.

Y10k (:

> 1) What is the reasoning behind 6 digit years? Surely any system contrived today will not exist in the year 100,000.

But ... I want someone to put together a simulator that can estimate where Voyager 2 will be at e.g. 020000-01-01

The ISO8601 standard is behind a paywall, and consequently many of the "ISO8601" functions in programming languages and libraries don't actually support anything but the subset that is also RFC 3339.

Also, it in includes support for a bunch of formats that aren't actually very useful in practice.

ISO 8601 has become popular enough that many systems take it as a shorthand for yyyy-mm-ddTHH:ii:ss.*, and perhaps the date only yyyy-mm-dd, without caring much about the other parts of the specifications.

It was a long time ago but I have memories of Apple's Objective C frameworks not supporting huge swaths of it. And it's worse for private systems that can just tell the clients to keep it inside the generic formats.

In that sense, ISO 8601 or RFC 3339 are virtually the same for many systems/companies.

man the year 10,000 is really going to break a lot of software systems that assume a 4 digit year

Possibly; this assumes that our current calendar's epoch holds, that humanity is still around, that computing systems are still around, and legacy software from 8,000 years past is still kicking people in the butt.

Given that electronic computing has only existed since approximately the 1930s, it's probably premature to worry about what will happen 8,000 years from now.

Worse case scenario we can get around to updating stuff by the time we hit the year 9,900 or so

Eh, that's gonna be their problem to unfuck software that assumes 4 digit years. I'm gonna be long dead and forgotten by then.

Not to worry. The calendar will be rebased when A.I. replaces J.C. as the starting point.

1) There's nothing special about 6 digit years. You can also use 5, or 7 digit years, or whatever the two parties can agree to before communication starts.

Part 2 of the standard gives examples of years with 10 digits.

Nah, email and classic Unix use entirely unrelated date formats. The RFC 822 format looks like "Thu, 31 Aug 2023 20:53:11". Unix / ctime(3) uses "Thu Aug 31 20:56:52 2023".

RFC 822 is what RSS feeds use and RFC 3339 is what Atom feeds use.

I don't know about you, but I think RFC 3339 dates are much more appealing :)

Perhaps 6 digit years are intended to be useful for representing prehistoric dates?