4 ms·
Two questions: 1) What is the reasoning behind 6 digit years? Surely any system contrived today will not exist in the year 100,000. 2) ISO 8601 is prolific. I
by Alupis 3y ago
Two questions:
1) What is the reasoning behind 6 digit years? Surely any system contrived today will not exist in the year 100,000.
2) ISO 8601 is prolific. Is RFC 3339 well used/adopted in any system?
- rowanseymour 3y agoI could imagine scientific tooling wanting to represent dates in the far future.
- paulddraper 3y agoY10k (:
- rendaw 3y agoBoth 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.
- Alupis 3y agoInteresting. 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.
- pdw 3y agoAlmost everything that claims to implement ISO 8601 actually implements RFC 3339 instead.
- rowanseymour 3y agoI think a lot of people assume ISO 8601 just means 2023-08-31 / 2023-08-31T14:55:30Z.. if only
- cryptonector 3y agoIt's ISO 8601, not RFC 8601 (which is `Message Header Field for Indicating Message Authentication Status`).
- verandaguy 3y agoIn fairness, it's doubtful that either Go's or Rust's time-handling facilities would implement support for an email auth header.
- Macha 3y agoThe 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.
- thayne 3y agoAlso, it in includes support for a bunch of formats that aren't actually very useful in practice.
- PhilipRoman 3y agoJudging 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.
- euroderf 3y agoFTL pod launch rails will be 4 feet 8.5 inches apart.
- throw0101a 3y ago> 2) ISO 8601 is prolific. Is RFC 3339 well used/adopted in any system? ISO 8601 was first published in 1988. RFC 3339, while ostensibly dated July 2002, codifies practices that date back to Usenet and e-mail (RFC 822: August 1982), and perhaps to the date utility (which existed in Version 1 AT&T UNIX).
- pdw 3y agoNah, 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".
- robobro 3y agoRFC 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 :)
- dabluck 3y agoman the year 10,000 is really going to break a lot of software systems that assume a 4 digit year
- chungy 3y agoPossibly; 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.
- airstrike 3y agoWorse case scenario we can get around to updating stuff by the time we hit the year 9,900 or so
- sph 3y agoEh, that's gonna be their problem to unfuck software that assumes 4 digit years. I'm gonna be long dead and forgotten by then.
- euroderf 3y agoNot to worry. The calendar will be rebased when A.I. replaces J.C. as the starting point.
- starlevel003 3y ago> 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.
- dwaite 3y agoA 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.
- noselasd 3y ago> 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
- mitthrowaway2 3y agoPerhaps 6 digit years are intended to be useful for representing prehistoric dates?
- ijmacd 3y ago1) 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.
- makeitdouble 3y agoISO 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.