17 ms·

RFC 3339 vs. ISO 8601

482 points by iamwil 3y ago

cratermoon 3y ago
Notice there is no format in which timezone is specified as 4 digits without the colon, and yet 'date +%z' returns ±NNNN.
- aendruk 3y ago
  Thankfully we have %:z. Relatedly, it’s possible to teach date to do this by default: https://gist.github.com/d081dad407432d53172e30d0d35c39db https://gist.github.com/d081dad407432d53172e30d0d35c39db $ date 2023-08-31T11:15:00-07:00
  - cratermoon 3y ago
    +%:z is a gnu-specific extension, though. The gist you linked works with gnu libc, but I'm not aware of a POSIX-compliant way to do it.
- ijmacd 3y ago
  > timezone is specified as 4 digits without the colon ±NNNN is valid (without colon) if used as part of the "basic" format. i.e. no hyphens or colons anywhere in the format. Thus the following are equivalent and both valid: 2023-09-01T09:40:01+08:00 20230901T094001+0800
  - cratermoon 3y ago
    Ah, I see that listed as a valid ISO 8601 format in the table, but not in the visualization, so I missed it. Also I can't say I've ever seen the basic format in the wild, is there anywhere it's used regularly?
    - chipsa 3y ago
      When the timestamp gets slammed into a file name, as the colon is reserved on Windows and MacOS. Also, when space matters, as it's very slightly shorter.
jmull 3y ago
What a great visualization for this. I'd prefer to use space (or underscore) instead of T to separate the date and time parts, but generally stick with T to avoid problems with anything that can only handle ISO 8601 (and to be consistent).
- cryptonector 3y ago
  I prefer T because nothing will be splitting these strings on T by accident.
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 ago
  I could imagine scientific tooling wanting to represent dates in the far future.
- paulddraper 3y ago
  Y10k (:
- rendaw 3y ago
  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.
  - Alupis 3y ago
    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.
    - pdw 3y ago
      Almost everything that claims to implement ISO 8601 actually implements RFC 3339 instead.
      - rowanseymour 3y ago
        I think a lot of people assume ISO 8601 just means 2023-08-31 / 2023-08-31T14:55:30Z.. if only
account-5 3y ago
Damn, the timeout for redirecting me to GitHub was too short for me to allow JavaScript in uBlock! Anyway, can someone with more experience tell me when the huge ISO 8601 would be of use over RFC 3339? I can't imagine any application using 1% of the random formats available.
- omoikane 3y ago
  ISO 8601 supports all sorts of corner cases, apparently. But it costs money to get the full standard, unlike RFCs. Someone bought a copy and was answering questions few years ago: https://www.reddit.com/r/ISO8601/comments/mikuj1/i_bought_iso_860112019_and_860122019_ask_me/ https://www.reddit.com/r/ISO8601/comments/mikuj1/i_bought_is... https://news.ycombinator.com/item?id=26672263 https://news.ycombinator.com/item?id=26672263
  - account-5 3y ago
    I was unaware that it cost money. RFC for me (I say like I'd have a clue how to implement any RFC).
    - asabil 3y ago
      ISO8601 is a standard managed by ISO, you can buy a digital or printed copy of the standard from here: https://www.iso.org/standard/70907.html https://www.iso.org/standard/70907.html RFC 3339 is managed by the IETF, and their documents are accessible free of charge.
      - mananaysiempre 3y ago
        > you can buy a digital or printed copy of the standard from [the ISO] Or from your national member body, which for some standards and countries can be substantially cheaper.
        seabass-labrax 3y ago
        In Britain, standards can sometimes be obtained for free via your library subscription (which would be orders of magnitude cheaper than the standards are directly, due to government subsidies for libraries).
Karellen 3y ago
I find it weird that there's no way to specify a future date/time with respect to a specific timezone, e.g. Europe/London. I don't think it's unreasonable to want to be able to specify a meeting in London, on July 1st 2030, at 6pm local time - no matter what happens to UK timezones between now and then. The UK currently uses Z+00:00 from November to March, and daylight savings of Z+01:00 from April to October (roughly)[0]. But it's possible that between now and 2030 they might adopt Central European (Summer) Time[1], or retry British Double Summer Time[2], or scrap daylight savings entirely. Therefore, what happens to 6pm with respect to any given epoch might vary wildly between now and 2030. But it would be nice to set a calendar event for "6pm London time", whatever London time happens to be when the event rolls around. But there's no standardised interoperable way to say "2030-07-01 18:00:00 Europe/London". [0] https://en.wikipedia.org/wiki/British_Summer_Time https://en.wikipedia.org/wiki/British_Summer_Time [1] https://en.wikipedia.org/wiki/Central_European_Time https://en.wikipedia.org/wiki/Central_European_Time [2] https://en.wikipedia.org/wiki/British_Summer_Time#Periods_of_deviation https://en.wikipedia.org/wiki/British_Summer_Time#Periods_of...
- ydnaclementine 3y ago
  Potential RFC idea?
- gorgoiler 3y ago
  Having the tzdata zone at the end, after a space, makes perfect sense. I think you just invented the new standard? A wall clock / human readable time without a TZ is like a… …a horse without a field? …a burger without knowing the meat? …a photograph of a star without a position? …a lover without a name? Ok maybe too far. …a bonus without knowing the currency?
  - jvanderbot 3y ago
    It's in ISO 8601. See the "Z"? that means "Zulu" or "+0". You can specify any offset. This is standardized and immutable. What offset is correct, however, can change due to local madness, and no standard could possibly keep up. But I do love the `date` utility, which allows alphanumeric time zone abbreviations pretty well.
Symbiote 3y ago
2023-08-31/28 I don't think that's valid, as the abbreviated form allows excluding identical parts, so expanded this is 2023-08-31/2023-08-28 which has the start time after the end.
jiehong 3y ago
Durations are pretty nice and seriously missing from the RFC.
- layer8 3y ago
  In the general case, durations can be non-intuitive or ambiguous when applied across DST changeovers or leap seconds, or when they include a month count.
  - l0b0 3y ago
    I don't think anybody involved in date/time programming disagrees, but I'd rather have a single standard for both than having to use two standards.
    - layer8 3y ago
      It’s a reason why generic durations aren’t often used. Usually you restrict it to be a simple count of seconds or days or whatever is appropriate for the use case, and then you don’t need any special notation, because it’s just a numerical quantity that you store/transmit like any other numerical quantity, its unit being implicit in the schema.
      - l0b0 3y ago
        That only works in simple cases, and has been the cause of countless bugs. A duration of 1 day is semantically different from 606024 seconds.
- teddyh 3y ago
  What do you mean, missing? Both durations and periods are defined in RFC 3339.
CodesInChaos 3y ago
One part of RFC 3339 I dislike is `Z` vs `+00:00` vs `-00:00` > Unknown Local Offset Convention > If the time in UTC is known, but the offset to local time is unknown, this can be represented with an offset of "-00:00". > This differs semantically from an offset of "Z" or "+00:00", which imply that UTC is the preferred reference point for the specified time. `Z` should have been used to represent the unknown local time case, and `-00:00` shouldn't exist, while `+00:00` could be used if UTC is the preferred reference point. In practice `Z` is already used for the "no preferred local time" case very often.
- burkaman 3y ago
  Wow that is very surprising, I always thought -00:00 was just a synonym for +00:00. That seems almost intentionally misleading, why not Z like you say or just +? or something?
  - deleted 3y ago
    [deleted]
  - foresto 3y ago
    Reminds me of the +1 / -1 / +0 / -0 convention that was once common in open source development discussions. For example: https://community.apache.org/committers/consensusBuilding.html#expressing-support-or-otherwise https://community.apache.org/committers/consensusBuilding.ht... I wonder if that convention had something to do with this choice of syntax.
- mankyd 3y ago
  Thank you for this comment. I saw the `-00:00` in the RFC 3339 bubble, and was confused as to why it wasn't mutually agreed upon. Your comment makes clear the the `-` has special meaning that I hadn't picked up on.
- toast0 3y ago
  I thought Z was a reference to (NATO) Military time zones [1], where Zulu Time Zone is equivalent to UTC+00:00, but uses fewer characters. iCal uses the Z to indicate times intentionally in UTC as well, as opposed to times without a time zone indicator (use unknown local time), or times with an explicity time zone indicator. Using Z to indicate 'please use whatever local time seems appropriate' seems like poor practice, even if it's a common one. [1] https://en.wikipedia.org/wiki/Military_time_zone https://en.wikipedia.org/wiki/Military_time_zone
coding123 3y ago
Time and money - the two things we literally can't solve even with AI.
kuon 3y ago
Most of the time RFC is the way to go as ISO specs are not available for free and many open source implementation are actually not fully open source compliant because based on drafts. It's also a really big effort for open source devs. Also, if you are working on anything dealing with date in the future, you nearly always want to store wall clock time + location. Sadly, there is no standard for that. In Europe and USA the timezones are quite stable, so we might not be confronted to this, but in many places timzones change quite often, and storing an offset is not stable. Having "june 5 2026, 13h30 wall clock, paris" is what most people will mean, and it might be UTC+2 or UTC+1 depending if EU finally decide on what to do with DST. And finally, if you write an API with times in the past, just use POSIX timestamps in seconds, ms, us or ns.
- toast0 3y ago
  > Also, if you are working on anything dealing with date in the future, you nearly always want to store wall clock time + location. Sadly, there is no standard for that. iCalendar is an RFC standard for this. [1] Note that some times have two representations and some times are not representable in this format when there's a time change due to DST. iCal also does not contemplate a location being reassigned to a different time zone, an issue discussed elsewhere in this thread. Of course, properly formatted iCal files also include data for all of the referenced timezones. Which makes it cumbersome if you just wanted to output a single datetime. [1] https://icalendar.org/iCalendar-RFC-5545/3-3-5-date-time.html https://icalendar.org/iCalendar-RFC-5545/3-3-5-date-time.htm...
- WorldMaker 3y ago
  There is a draft standard called IXDTF that extends RFC 3339 to include the IANA timezone names in square brackets: 2026-06-05T13:30+0200[Europe/Paris] https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-extended-09.html https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-e...
  - kuon 3y ago
    That is very promising! But as timezones change, we need place names, not timezone names.
devmunchies 3y ago
An often ignored part of the standards are how to represent durations (time spans). See http://xml.coverpages.org/ISO-FDIS-8601.pdf http://xml.coverpages.org/ISO-FDIS-8601.pdf (section: 5.5.4.2 Representation of time-interval by duration only, pg. 21) Would like to see more json parsers in static languages allow me to define a field as a time span and can serialize into the valid format. For an example, see this proposal in Crystal: https://github.com/crystal-lang/crystal/issues/11942 https://github.com/crystal-lang/crystal/issues/11942 Example: A duration of 15 days, 5 hours, and 20 seconds would be: P15DT5H0M20S A duration of 7 weeks would be: P7W
- duped 3y ago
  Why do you want a string format for data that can be structured? "duration": { "days": 15, "hours": 5, "seconds": 20 } Now it's not the job of your JSON parser to understand the semantics of your data. It's your input validator's - which is how it should be, imo. Note you will have to have some fallible conversion step from whatever JSON chooses to represent that data as anyway.
  - atoav 3y ago
    Because there can be benefits to having it compact and yet human readable? 2023-08-24T20:30:00Z versus "time" : { "year" : 2023, "month" : 8, "day" : 24, "hour" : 20, "minute" : 30, "second" : 0, "timezone" : "UTC", } Call me lazy, but tryping the latter took me 20 times longer. I totally would use it for internal state, but I would not store it like that or expose that to users ever.
    - duped 3y ago
      But you're talking about JSON, not a concise string that is exposed to users, and not a data format optimized for size. If you want more than a basic type you give it structure - and durations are not trivial types nor common enough to deserve their own representation. Durations optimized for storage without ambiguity would be the tuple (u64, u32, u8) where the first value is seconds, second value is nanoseconds (if precision is needed) and final value is epoch. Durations displayed to a user wouldn't ever be stored so the point is kind of moot. Optimizing for "time it takes someone to write it once" is kind of dumb since it happens once while reading it happens often, and parsing even more likely.
ledauphin 3y ago
the tables agree that microseconds are supported by both standards, but for some reason the Venn Diagram only displays 6-digit fractional seconds under ISO8601. This led me to do some head-scratching until I referenced the table, which seems a lot more comprehensive. This is extremely cool and useful overall, but unfortunately the Venn Diagram seems to be slightly misleading.
- ijmacd 3y ago
  Hey thanks for pointing this out. Every time this gets posted to HN someone notices something else. The format you spotted in the Venn diagram was: 2023-09-01T10:12:07.284307 This is indeed only valid under ISO 8601 since RFC 3339 always requires a timezone. So the Venn diagram wasn't wrong, but I agree it was misleading. I've now updated the diagram to add the following format, which is valid under both standards: 2023-09-01T02:12:07.284307Z
  - ledauphin 3y ago
    hey, thanks for putting this out there and also for iterating on it! I will start using sending this to folks as a reference now that I know it's being maintained!
NikkiA 3y ago
6 digit years seem like a solution to a problem that will never be for the sake of looking forward thinking. There's absolutely no way current technology or social norms will last 8000 years.
- sedatk 3y ago
  It just makes great easter eggs. "Hey, this guy had set his reminder to today. I wonder what he'd think if he knew we actually saw this 56,000 years later" "Well, let's regenerate him and ask"
- atoav 3y ago
  Yeah, but don't forget we use computers for things that don't involve today only. Let's say you run a climate calculation for long enough for example. Now you could just say "fuck dates" if they error — but wouldn't it be kinda nice if they didn't?
  - tgv 3y ago
    If you want to project something beyond 9999-12-31, you can do that with custom timestamps, e.g. by specifying the year as a float. There's no need to convert that back to a timezone or sync it to UTC. The maximum difference of 1 day would be 0.00003% in 10K and decreasing, a level of accuracy no simulation can ever achieve.
  - NikkiA 3y ago
    Would you really need a full date and time stamp for doing that? If you're talking about projections 10,000 years in the future do you care if it's mid-afternoon on a tuesday?
- ijmacd 3y ago
  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.
- alphager 3y ago
  6 digit years are a solution for a problem we have today. Think geologist simulating continental drift.
MattSteelblade 3y ago
It bothers me on a regular basis that there is no RFC 3339 acceptable way to include date and time in a file name in Windows as a colon is a special character. I also wish you could use hyphens in the date while ignoring the colons and still be ISO 8601 compliant, for example 20230831T1510-0500 is compliant and can be used in a filename, while 2023-08-31T1510-0500 (and similar variants) is not. As an aside the "Get-Date" function in PowerShell doesn't understand the first timestamp without the hyphens and colon.
- tengwar2 3y ago
  I hadn't realised that there was a problem with Windows. MacOS has a different problem with a colon in a file name. For two of the three most popular operating systems to have this problem does show a distinct lack of thought.
- cryptonector 3y ago
  Removing the colons is perfectly safe and will not render RFC3339 dates and date-times ambiguous, and you can always losslessly restore those colons.
lifthrasiir 3y ago
> ISO 8601 uses a hyphen character (in Unicode, U+2010 HYPHEN "‐") and minus character (in Unicode, U+2212 MINUS "−"). When using character sets which don't have these characters a hyphen-minus character (in Unicode, U+2D HYPHEN-MINUS "-") should be used instead. This is incorrect. What ISO 8601 actually specifies is that, if the target character set is based on ISO/IEC 646 (which definitely includes Unicode), then a hyphen-minus character should be used for both cases. There is a slight ambiguity here (e.g. what if some charset contains most but not all characters in 646?) but in the case of Unicode the interpretation is clear. I believe this is a roundabout way to specify the canonical mapping for 646 and guarantee the compatibility with other charsets based on 646.
- ijmacd 3y ago
  That's very interesting. The relevant paragraph from the standard is in ISO 8601-1:2019 §3.2.1: > All characters used in date and time expressions and representations are part of the ISO/IEC 646 repertoire, except for “hyphen”, “minus” and “plus-minus”. In an environment where use is made of a character repertoire based on ISO/IEC 646, “hyphen” and “minus” should be both mapped onto “hyphen-minus”. And as you correctly state, Unicode is based on ISO 8859 which is based on ISO 646. So it would seem the intention really is to use U+2D hyphen-minus when Unicode is the character set.
- deleted 3y ago
  [deleted]
krick 3y ago
It's "funny" how both RFC 3339 and ISO 8601 standards include a huge number of redundant DT formats with often overlapping purposes, yet "2023-09-01 15:30:59", which is by far most used DT format (because it's fucking obvious!) across all systems is included in neither. Also, both standards are very unclear on how to represent DTs BC, and how to represent DTs after 9999-12-31 (or before -9999-01-01), and most commonly used libraries often just cannot handle them at all. And even when they can, the behavior of 00-01-01 is basically undefined (may I remind you, that Gregorian calendar is stupid, and the next year after 1 BC is 1 CE). In short, basically no software except for specialized astronomical software handles anything beyond near-future unix-time, even though for most purposes (like, uniformly representing DOB/DOD of Emperor Augustus) it's really not rocket science (we are really ok with just storing strings) and just needs to be clearly defined in some standard!
- Zuiii 3y ago
  > It's "funny" how both RFC 3339 and ISO 8601 standards include a huge number of redundant DT formats with often overlapping purposes, yet "2023-09-01 15:30:59", which is by far most used DT format (because it's fucking obvious!) across all systems is included in neither. It's much readable too. I recently started ignoring both standards in favor of the nicer space-separated format after almost two decades of sticking with the former. I get why they needed a non-whitespace character but they could have at least used an underscore or a dot. And I have no idea why they sacrificed the universality of the format by limiting the year segment to only four digits. It's a string!
  - krick 3y ago
    Yes, that's what I mean by "obvious". And I mean to say that it's REALLY important IMO. The point of having a standard is to abandon ALL other ways of representing a DT (or at least go as far as possible in that direction). RFC 3339 and ISO 8601 make that basically impossible. Most of your coworkers (let alone non-technical business people) don't give a damn (or even know anything, really) about standards and will represent DTs differently in different places. I can force them to use 2023-09-20 instead of 2023/09/20, and MAYBE even instead of mind-boggling USA-ian format of 09/20/2023, but I sure as hell cannot force them to use "2023-09-20T20:30:59" instead of "2023-09-20 20:30:59". Because it's less readable, and it's not arguable. > And I have no idea why they sacrificed the universality of the format by limiting the year segment to only four digits No, there are reasons. People often represent year with 2 digits, so forcing you to use 4 digits is basically intended to make representing 20 CE unambiguous as 0020-01-01 (as opposed to 20-01-01). But, I mean, it's a problem to be mindful of when making a standard, not an insurmountable obstacle. A real standard to end other formats once and for all just needs to make sure to take care of all corner-cases. The truth is RFC 3339 and ISO 8601 are just shitty standards. (Edit: Also, just in case, note that it is possible to use 5 or more digits in ISO 8601. But the standard says that the parties must agree beforehand on that. That's what I mean by "unclear". I cannot just say that you MUST represent DT in ISO-XXXX format, it's not specific enough. In the end we must to agree on how our systems will behave when receiving this or that value anyway, so it makes having an external "standard" pretty pointless, since the standard is pretty clear about very obvious situations, and very hand-wavy in all actually non-trivial situations.)
stkdump 3y ago
JS date format pretty much lives at the intersection of them, afaict, so it should be the perfect choice for interoperability. Also, I gather it makes working with dates simpler if you can rely on a less variable format.
politelemon 3y ago
What format can be used to output 6 digit years? I do see 002023 in the examples but not the table.
majke 3y ago
oh, oh. I know what. I don't know much about the context, but I remember that datetime parsing code in Firefox was one of the messiest parsers around: https://searchfox.org/mozilla-central/source/nsprpub/pr/src/misc/prtime.c#944 https://searchfox.org/mozilla-central/source/nsprpub/pr/src/... (I guess that means that at least in the context of browsers, it's far from standardized)
- lifthrasiir 3y ago
  For the context, ECMAScript allows for any implementation-defined format besides from the mandatory ISO 8601 style format [1]. Browsers are noticably different here [2]; the equivalent `v8::internal::DateParser` class is no better. [1] https://262.ecma-international.org/#sec-date.parse https://262.ecma-international.org/#sec-date.parse [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse#non-standard_date_strings https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
deleted 3y ago
[deleted]

482 points by iamwil 3y ago

Notice there is no format in which timezone is specified as 4 digits without the colon, and yet 'date +%z' returns ±NNNN.

aendruk 3y ago
Thankfully we have %:z. Relatedly, it’s possible to teach date to do this by default: https://gist.github.com/d081dad407432d53172e30d0d35c39db https://gist.github.com/d081dad407432d53172e30d0d35c39db $ date 2023-08-31T11:15:00-07:00
- cratermoon 3y ago
  +%:z is a gnu-specific extension, though. The gist you linked works with gnu libc, but I'm not aware of a POSIX-compliant way to do it.
ijmacd 3y ago
> timezone is specified as 4 digits without the colon ±NNNN is valid (without colon) if used as part of the "basic" format. i.e. no hyphens or colons anywhere in the format. Thus the following are equivalent and both valid: 2023-09-01T09:40:01+08:00 20230901T094001+0800
- cratermoon 3y ago
  Ah, I see that listed as a valid ISO 8601 format in the table, but not in the visualization, so I missed it. Also I can't say I've ever seen the basic format in the wild, is there anywhere it's used regularly?
  - chipsa 3y ago
    When the timestamp gets slammed into a file name, as the colon is reserved on Windows and MacOS. Also, when space matters, as it's very slightly shorter.

jmull 3y ago

What a great visualization for this. I'd prefer to use space (or underscore) instead of T to separate the date and time parts, but generally stick with T to avoid problems with anything that can only handle ISO 8601 (and to be consistent).

cryptonector 3y ago
I prefer T because nothing will be splitting these strings on T by accident.

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 ago
I could imagine scientific tooling wanting to represent dates in the far future.
paulddraper 3y ago
Y10k (:
rendaw 3y ago
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.
- Alupis 3y ago
  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.
  - pdw 3y ago
    Almost everything that claims to implement ISO 8601 actually implements RFC 3339 instead.
    - rowanseymour 3y ago
      I think a lot of people assume ISO 8601 just means 2023-08-31 / 2023-08-31T14:55:30Z.. if only

account-5 3y ago

Damn, the timeout for redirecting me to GitHub was too short for me to allow JavaScript in uBlock! Anyway, can someone with more experience tell me when the huge ISO 8601 would be of use over RFC 3339? I can't imagine any application using 1% of the random formats available.

omoikane 3y ago
ISO 8601 supports all sorts of corner cases, apparently. But it costs money to get the full standard, unlike RFCs. Someone bought a copy and was answering questions few years ago: https://www.reddit.com/r/ISO8601/comments/mikuj1/i_bought_iso_860112019_and_860122019_ask_me/ https://www.reddit.com/r/ISO8601/comments/mikuj1/i_bought_is... https://news.ycombinator.com/item?id=26672263 https://news.ycombinator.com/item?id=26672263
- account-5 3y ago
  I was unaware that it cost money. RFC for me (I say like I'd have a clue how to implement any RFC).
  - asabil 3y ago
    ISO8601 is a standard managed by ISO, you can buy a digital or printed copy of the standard from here: https://www.iso.org/standard/70907.html https://www.iso.org/standard/70907.html RFC 3339 is managed by the IETF, and their documents are accessible free of charge.
    - mananaysiempre 3y ago
      > you can buy a digital or printed copy of the standard from [the ISO] Or from your national member body, which for some standards and countries can be substantially cheaper.
      - seabass-labrax 3y ago
        In Britain, standards can sometimes be obtained for free via your library subscription (which would be orders of magnitude cheaper than the standards are directly, due to government subsidies for libraries).

Karellen 3y ago

I find it weird that there's no way to specify a future date/time with respect to a specific timezone, e.g. Europe/London. I don't think it's unreasonable to want to be able to specify a meeting in London, on July 1st 2030, at 6pm local time - no matter what happens to UK timezones between now and then. The UK currently uses Z+00:00 from November to March, and daylight savings of Z+01:00 from April to October (roughly)[0]. But it's possible that between now and 2030 they might adopt Central European (Summer) Time[1], or retry British Double Summer Time[2], or scrap daylight savings entirely. Therefore, what happens to 6pm with respect to any given epoch might vary wildly between now and 2030. But it would be nice to set a calendar event for "6pm London time", whatever London time happens to be when the event rolls around. But there's no standardised interoperable way to say "2030-07-01 18:00:00 Europe/London". [0] https://en.wikipedia.org/wiki/British_Summer_Time https://en.wikipedia.org/wiki/British_Summer_Time [1] https://en.wikipedia.org/wiki/Central_European_Time https://en.wikipedia.org/wiki/Central_European_Time [2] https://en.wikipedia.org/wiki/British_Summer_Time#Periods_of_deviation https://en.wikipedia.org/wiki/British_Summer_Time#Periods_of...

ydnaclementine 3y ago
Potential RFC idea?
gorgoiler 3y ago
Having the tzdata zone at the end, after a space, makes perfect sense. I think you just invented the new standard? A wall clock / human readable time without a TZ is like a… …a horse without a field? …a burger without knowing the meat? …a photograph of a star without a position? …a lover without a name? Ok maybe too far. …a bonus without knowing the currency?
- jvanderbot 3y ago
  It's in ISO 8601. See the "Z"? that means "Zulu" or "+0". You can specify any offset. This is standardized and immutable. What offset is correct, however, can change due to local madness, and no standard could possibly keep up. But I do love the `date` utility, which allows alphanumeric time zone abbreviations pretty well.

Symbiote 3y ago

2023-08-31/28 I don't think that's valid, as the abbreviated form allows excluding identical parts, so expanded this is 2023-08-31/2023-08-28 which has the start time after the end.

jiehong 3y ago

Durations are pretty nice and seriously missing from the RFC.

layer8 3y ago
In the general case, durations can be non-intuitive or ambiguous when applied across DST changeovers or leap seconds, or when they include a month count.
- l0b0 3y ago
  I don't think anybody involved in date/time programming disagrees, but I'd rather have a single standard for both than having to use two standards.
  - layer8 3y ago
    It’s a reason why generic durations aren’t often used. Usually you restrict it to be a simple count of seconds or days or whatever is appropriate for the use case, and then you don’t need any special notation, because it’s just a numerical quantity that you store/transmit like any other numerical quantity, its unit being implicit in the schema.
    - l0b0 3y ago
      That only works in simple cases, and has been the cause of countless bugs. A duration of 1 day is semantically different from 606024 seconds.
teddyh 3y ago
What do you mean, missing? Both durations and periods are defined in RFC 3339.

CodesInChaos 3y ago

One part of RFC 3339 I dislike is `Z` vs `+00:00` vs `-00:00` > Unknown Local Offset Convention > If the time in UTC is known, but the offset to local time is unknown, this can be represented with an offset of "-00:00". > This differs semantically from an offset of "Z" or "+00:00", which imply that UTC is the preferred reference point for the specified time. `Z` should have been used to represent the unknown local time case, and `-00:00` shouldn't exist, while `+00:00` could be used if UTC is the preferred reference point. In practice `Z` is already used for the "no preferred local time" case very often.

burkaman 3y ago
Wow that is very surprising, I always thought -00:00 was just a synonym for +00:00. That seems almost intentionally misleading, why not Z like you say or just +? or something?
- deleted 3y ago
  [deleted]
- foresto 3y ago
  Reminds me of the +1 / -1 / +0 / -0 convention that was once common in open source development discussions. For example: https://community.apache.org/committers/consensusBuilding.html#expressing-support-or-otherwise https://community.apache.org/committers/consensusBuilding.ht... I wonder if that convention had something to do with this choice of syntax.
mankyd 3y ago
Thank you for this comment. I saw the `-00:00` in the RFC 3339 bubble, and was confused as to why it wasn't mutually agreed upon. Your comment makes clear the the `-` has special meaning that I hadn't picked up on.
toast0 3y ago
I thought Z was a reference to (NATO) Military time zones [1], where Zulu Time Zone is equivalent to UTC+00:00, but uses fewer characters. iCal uses the Z to indicate times intentionally in UTC as well, as opposed to times without a time zone indicator (use unknown local time), or times with an explicity time zone indicator. Using Z to indicate 'please use whatever local time seems appropriate' seems like poor practice, even if it's a common one. [1] https://en.wikipedia.org/wiki/Military_time_zone https://en.wikipedia.org/wiki/Military_time_zone

coding123 3y ago

Time and money - the two things we literally can't solve even with AI.

kuon 3y ago

Most of the time RFC is the way to go as ISO specs are not available for free and many open source implementation are actually not fully open source compliant because based on drafts. It's also a really big effort for open source devs. Also, if you are working on anything dealing with date in the future, you nearly always want to store wall clock time + location. Sadly, there is no standard for that. In Europe and USA the timezones are quite stable, so we might not be confronted to this, but in many places timzones change quite often, and storing an offset is not stable. Having "june 5 2026, 13h30 wall clock, paris" is what most people will mean, and it might be UTC+2 or UTC+1 depending if EU finally decide on what to do with DST. And finally, if you write an API with times in the past, just use POSIX timestamps in seconds, ms, us or ns.

toast0 3y ago
> Also, if you are working on anything dealing with date in the future, you nearly always want to store wall clock time + location. Sadly, there is no standard for that. iCalendar is an RFC standard for this. [1] Note that some times have two representations and some times are not representable in this format when there's a time change due to DST. iCal also does not contemplate a location being reassigned to a different time zone, an issue discussed elsewhere in this thread. Of course, properly formatted iCal files also include data for all of the referenced timezones. Which makes it cumbersome if you just wanted to output a single datetime. [1] https://icalendar.org/iCalendar-RFC-5545/3-3-5-date-time.html https://icalendar.org/iCalendar-RFC-5545/3-3-5-date-time.htm...
WorldMaker 3y ago
There is a draft standard called IXDTF that extends RFC 3339 to include the IANA timezone names in square brackets: 2026-06-05T13:30+0200[Europe/Paris] https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-extended-09.html https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-e...
- kuon 3y ago
  That is very promising! But as timezones change, we need place names, not timezone names.

devmunchies 3y ago

An often ignored part of the standards are how to represent durations (time spans). See http://xml.coverpages.org/ISO-FDIS-8601.pdf http://xml.coverpages.org/ISO-FDIS-8601.pdf (section: 5.5.4.2 Representation of time-interval by duration only, pg. 21) Would like to see more json parsers in static languages allow me to define a field as a time span and can serialize into the valid format. For an example, see this proposal in Crystal: https://github.com/crystal-lang/crystal/issues/11942 https://github.com/crystal-lang/crystal/issues/11942 Example: A duration of 15 days, 5 hours, and 20 seconds would be: P15DT5H0M20S A duration of 7 weeks would be: P7W

duped 3y ago
Why do you want a string format for data that can be structured? "duration": { "days": 15, "hours": 5, "seconds": 20 } Now it's not the job of your JSON parser to understand the semantics of your data. It's your input validator's - which is how it should be, imo. Note you will have to have some fallible conversion step from whatever JSON chooses to represent that data as anyway.
- atoav 3y ago
  Because there can be benefits to having it compact and yet human readable? 2023-08-24T20:30:00Z versus "time" : { "year" : 2023, "month" : 8, "day" : 24, "hour" : 20, "minute" : 30, "second" : 0, "timezone" : "UTC", } Call me lazy, but tryping the latter took me 20 times longer. I totally would use it for internal state, but I would not store it like that or expose that to users ever.
  - duped 3y ago
    But you're talking about JSON, not a concise string that is exposed to users, and not a data format optimized for size. If you want more than a basic type you give it structure - and durations are not trivial types nor common enough to deserve their own representation. Durations optimized for storage without ambiguity would be the tuple (u64, u32, u8) where the first value is seconds, second value is nanoseconds (if precision is needed) and final value is epoch. Durations displayed to a user wouldn't ever be stored so the point is kind of moot. Optimizing for "time it takes someone to write it once" is kind of dumb since it happens once while reading it happens often, and parsing even more likely.

ledauphin 3y ago

the tables agree that microseconds are supported by both standards, but for some reason the Venn Diagram only displays 6-digit fractional seconds under ISO8601. This led me to do some head-scratching until I referenced the table, which seems a lot more comprehensive. This is extremely cool and useful overall, but unfortunately the Venn Diagram seems to be slightly misleading.

ijmacd 3y ago
Hey thanks for pointing this out. Every time this gets posted to HN someone notices something else. The format you spotted in the Venn diagram was: 2023-09-01T10:12:07.284307 This is indeed only valid under ISO 8601 since RFC 3339 always requires a timezone. So the Venn diagram wasn't wrong, but I agree it was misleading. I've now updated the diagram to add the following format, which is valid under both standards: 2023-09-01T02:12:07.284307Z
- ledauphin 3y ago
  hey, thanks for putting this out there and also for iterating on it! I will start using sending this to folks as a reference now that I know it's being maintained!

NikkiA 3y ago

6 digit years seem like a solution to a problem that will never be for the sake of looking forward thinking. There's absolutely no way current technology or social norms will last 8000 years.

sedatk 3y ago
It just makes great easter eggs. "Hey, this guy had set his reminder to today. I wonder what he'd think if he knew we actually saw this 56,000 years later" "Well, let's regenerate him and ask"
atoav 3y ago
Yeah, but don't forget we use computers for things that don't involve today only. Let's say you run a climate calculation for long enough for example. Now you could just say "fuck dates" if they error — but wouldn't it be kinda nice if they didn't?
- tgv 3y ago
  If you want to project something beyond 9999-12-31, you can do that with custom timestamps, e.g. by specifying the year as a float. There's no need to convert that back to a timezone or sync it to UTC. The maximum difference of 1 day would be 0.00003% in 10K and decreasing, a level of accuracy no simulation can ever achieve.
- NikkiA 3y ago
  Would you really need a full date and time stamp for doing that? If you're talking about projections 10,000 years in the future do you care if it's mid-afternoon on a tuesday?
ijmacd 3y ago
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.
alphager 3y ago
6 digit years are a solution for a problem we have today. Think geologist simulating continental drift.

MattSteelblade 3y ago

It bothers me on a regular basis that there is no RFC 3339 acceptable way to include date and time in a file name in Windows as a colon is a special character. I also wish you could use hyphens in the date while ignoring the colons and still be ISO 8601 compliant, for example 20230831T1510-0500 is compliant and can be used in a filename, while 2023-08-31T1510-0500 (and similar variants) is not. As an aside the "Get-Date" function in PowerShell doesn't understand the first timestamp without the hyphens and colon.

tengwar2 3y ago
I hadn't realised that there was a problem with Windows. MacOS has a different problem with a colon in a file name. For two of the three most popular operating systems to have this problem does show a distinct lack of thought.
cryptonector 3y ago
Removing the colons is perfectly safe and will not render RFC3339 dates and date-times ambiguous, and you can always losslessly restore those colons.

lifthrasiir 3y ago

> ISO 8601 uses a hyphen character (in Unicode, U+2010 HYPHEN "‐") and minus character (in Unicode, U+2212 MINUS "−"). When using character sets which don't have these characters a hyphen-minus character (in Unicode, U+2D HYPHEN-MINUS "-") should be used instead. This is incorrect. What ISO 8601 actually specifies is that, if the target character set is based on ISO/IEC 646 (which definitely includes Unicode), then a hyphen-minus character should be used for both cases. There is a slight ambiguity here (e.g. what if some charset contains most but not all characters in 646?) but in the case of Unicode the interpretation is clear. I believe this is a roundabout way to specify the canonical mapping for 646 and guarantee the compatibility with other charsets based on 646.

ijmacd 3y ago
That's very interesting. The relevant paragraph from the standard is in ISO 8601-1:2019 §3.2.1: > All characters used in date and time expressions and representations are part of the ISO/IEC 646 repertoire, except for “hyphen”, “minus” and “plus-minus”. In an environment where use is made of a character repertoire based on ISO/IEC 646, “hyphen” and “minus” should be both mapped onto “hyphen-minus”. And as you correctly state, Unicode is based on ISO 8859 which is based on ISO 646. So it would seem the intention really is to use U+2D hyphen-minus when Unicode is the character set.
deleted 3y ago
[deleted]

krick 3y ago

It's "funny" how both RFC 3339 and ISO 8601 standards include a huge number of redundant DT formats with often overlapping purposes, yet "2023-09-01 15:30:59", which is by far most used DT format (because it's fucking obvious!) across all systems is included in neither. Also, both standards are very unclear on how to represent DTs BC, and how to represent DTs after 9999-12-31 (or before -9999-01-01), and most commonly used libraries often just cannot handle them at all. And even when they can, the behavior of 00-01-01 is basically undefined (may I remind you, that Gregorian calendar is stupid, and the next year after 1 BC is 1 CE). In short, basically no software except for specialized astronomical software handles anything beyond near-future unix-time, even though for most purposes (like, uniformly representing DOB/DOD of Emperor Augustus) it's really not rocket science (we are really ok with just storing strings) and just needs to be clearly defined in some standard!

Zuiii 3y ago
> It's "funny" how both RFC 3339 and ISO 8601 standards include a huge number of redundant DT formats with often overlapping purposes, yet "2023-09-01 15:30:59", which is by far most used DT format (because it's fucking obvious!) across all systems is included in neither. It's much readable too. I recently started ignoring both standards in favor of the nicer space-separated format after almost two decades of sticking with the former. I get why they needed a non-whitespace character but they could have at least used an underscore or a dot. And I have no idea why they sacrificed the universality of the format by limiting the year segment to only four digits. It's a string!
- krick 3y ago
  Yes, that's what I mean by "obvious". And I mean to say that it's REALLY important IMO. The point of having a standard is to abandon ALL other ways of representing a DT (or at least go as far as possible in that direction). RFC 3339 and ISO 8601 make that basically impossible. Most of your coworkers (let alone non-technical business people) don't give a damn (or even know anything, really) about standards and will represent DTs differently in different places. I can force them to use 2023-09-20 instead of 2023/09/20, and MAYBE even instead of mind-boggling USA-ian format of 09/20/2023, but I sure as hell cannot force them to use "2023-09-20T20:30:59" instead of "2023-09-20 20:30:59". Because it's less readable, and it's not arguable. > And I have no idea why they sacrificed the universality of the format by limiting the year segment to only four digits No, there are reasons. People often represent year with 2 digits, so forcing you to use 4 digits is basically intended to make representing 20 CE unambiguous as 0020-01-01 (as opposed to 20-01-01). But, I mean, it's a problem to be mindful of when making a standard, not an insurmountable obstacle. A real standard to end other formats once and for all just needs to make sure to take care of all corner-cases. The truth is RFC 3339 and ISO 8601 are just shitty standards. (Edit: Also, just in case, note that it is possible to use 5 or more digits in ISO 8601. But the standard says that the parties must agree beforehand on that. That's what I mean by "unclear". I cannot just say that you MUST represent DT in ISO-XXXX format, it's not specific enough. In the end we must to agree on how our systems will behave when receiving this or that value anyway, so it makes having an external "standard" pretty pointless, since the standard is pretty clear about very obvious situations, and very hand-wavy in all actually non-trivial situations.)

stkdump 3y ago

JS date format pretty much lives at the intersection of them, afaict, so it should be the perfect choice for interoperability. Also, I gather it makes working with dates simpler if you can rely on a less variable format.

politelemon 3y ago

What format can be used to output 6 digit years? I do see 002023 in the examples but not the table.

majke 3y ago

oh, oh. I know what. I don't know much about the context, but I remember that datetime parsing code in Firefox was one of the messiest parsers around: https://searchfox.org/mozilla-central/source/nsprpub/pr/src/misc/prtime.c#944 https://searchfox.org/mozilla-central/source/nsprpub/pr/src/... (I guess that means that at least in the context of browsers, it's far from standardized)

lifthrasiir 3y ago
For the context, ECMAScript allows for any implementation-defined format besides from the mandatory ISO 8601 style format [1]. Browsers are noticably different here [2]; the equivalent `v8::internal::DateParser` class is no better. [1] https://262.ecma-international.org/#sec-date.parse https://262.ecma-international.org/#sec-date.parse [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse#non-standard_date_strings https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

deleted 3y ago

[deleted]