6 ms·

One should use RFC 3339 dates which have a formal grammar and and open standard.

by koblas 6y ago

chrismeller 6y ago
Absolutely. They even reference ISO 8601 in the spec when specifying that the T and Z can also be lowercase. As far as I’m aware, the only difference between the two is something related to the - in the time zone offset... though I’ve also seen plenty of libraries parse 8601 with and without -, so it seems not to be super important.
- d0mine 6y ago
  rfc3339 is a profile of iso8601 i.e., every rfc3339 date is also iso8601 date but not in reverse
  - chrismeller 6y ago
    Do you have an example of an 8601 that is not 3339 compliant? I’ve never looked at any of the abbreviated formats, but if you’re giving a full date, time, and offset it seems identical (aside from that -).
    - ncallaway 6y ago
      Sure! 2021-W07-5
      - deleted 6y ago
        [deleted]
      - chrismeller 6y ago
        Ahh, you got me. I thought I had mentioned that I had never looked at any of the formats for shorter than full date, time, and offset strings. D’oh!
        ncallaway 6y ago
        I'm _fairly_ sure that 2021-W07-5T00:00:00Z or 2000-W03-7T01:23:45.678+09:00 would be a valid full ISO date time and offset as well, but I haven't checked the specification. Luxon will happily parse 2021-W07-5T00:00:00Z and tell me that it represents 2021-02-18T16:00:00.000-08:00, so I think it's valid.
    - Darkphibre 6y ago
      "Funny" story about a binary 8601 implementation. I was architecting a true-realtime telemetry pipeline for a AAA videogame studio (later used by a dozen or so franchises for all titles by the publisher). It had a requirement for subsecond client notification of per-user aggregated statistics, including complicated event interactions (such as ensuring the grenade that you threw that killed someone, would only be attributed to you if a prior event hadn't already occured), which resulted in sequentiality guarantees. But with that, we could get rid of windowed event processing (and those inherent latencies), and instead treat them as a true stream of events. Keep in mind we could support up to 400ms one-way latency, so we only had 200ms for processing/routing in the client and in the cloud. I measured client code in μs. Annnyways. The principal in our org insisted that time not be be transmitted as an epoch. I argued for weeks, but he was insistent... "No magical offsets to arbitrary dates. ISO8601. Do it." He came from and worked most heavily with the web services group. Apparently some point in the past, services had picked the wrong epoch and there was confusion (I still can't understand how that wouldn't be caught right away, there's only a few standard epochs that are quite different in resulting time)? The events in my design were bit-packed using a competing protocol to Protocol Buffers... there's no way I was doubling the payloads just to store a timestamp as a string. So I read and re-read ISO8601. And it dawned on me: ISO-8601 never specifies the encoding. It specifies the order in which information is conveyed, and if in text, the delimiters to use. One example clue is in the definition of basic format, and the call-out that most of the document leverages plain text to communicate their ideas. basic format format of a date and time representation or date and time format representation comprising the minimum number of time elements necessary for the accuracy required. The basic format should be avoided in plain text. I ended up proposing the most terrible hack I've had to live with. It involved bit-packed 64-bit integer that stored: 12 bits for year, 4 bits for month, 5 bits for date, 5 bits for hours, 6 bits for minutes, 6 bits for seconds, and the remaining bits for an integer that stores the sub-second fraction. We lost a few orders of magnitude resolution on that end due to the inefficiencies of the earlier packing, but... it worked. And it was in the right order. And there were no "magic" epochs to dissuade the principal engineer. Most importantly, it sailed through the review process. Still makes my skin crawl a decade later. And I secretly suspect you technically have to have a T between date and time to be ISO8601 compliant, it's been a long while since I read the spec. But there you go.
    - andoriyu 6y ago
      Sure, `20201209T160953Z` or 2021-123.
  - seagreen 6y ago
    This gets repeated a lot but unfortunately isn't true. See the spec: https://tools.ietf.org/html/rfc3339 https://tools.ietf.org/html/rfc3339 NOTE: ISO 8601 defines date and time separated by "T". Applications using this syntax may choose, for the sake of readability, to specify a full-date and full-time separated by (say) a space character. Someday someone reading this is going to set out to make a new, small specification out of a huge specification. Reader, when you start to feel the temptation to make just the tiniest improvement-- resist! It's way more useful if it's actually a true subset. Happily this particular issue is be easily fixed. Let's make a new spec, subsetting both ISO 8601 and RFC 3339. I hereby introduce... RFC 3339T, which is exactly like RFC 3339, but you have to use a T instead of a space. EDIT: joshuaissac spotted another difference. Also I made a repo so we're official: https://github.com/seagreen/rfc-3339T https://github.com/seagreen/rfc-3339T
    - joshuaissac 6y ago
      RFC 3339 also allows the offset -00:00 where the UTC time is known but the local time is not. The ISO standard does not permit this.
      - seagreen 6y ago
        Ooh, interesting. I made a GitHub repo for the new spec and credited you (https://github.com/seagreen/rfc-3339T https://github.com/seagreen/rfc-3339T). Let me know if you have more suggestions!
      - fanf2 6y ago
        -00:00 is permitted by ISO 8601 but it implies that the local time is the same as UTC, it does not imply that the local time is unknown.
        seagreen 6y ago
        Is Wikipedia wrong? It claims (https://en.wikipedia.org/wiki/ISO_8601 https://en.wikipedia.org/wiki/ISO_8601): An offset of zero, in addition to having the special representation "Z", can also be stated numerically as "+00:00", "+0000", or "+00". However, it is not permitted to state it numerically with a negative sign, as "−00:00", "−0000", or "−00"." Sure would be nice if we could read the spec online:)

One should use RFC 3339 dates which have a formal grammar and and open standard.

by koblas 6y ago

One should use RFC 3339 dates which have a formal grammar and and open standard.

Absolutely. They even reference ISO 8601 in the spec when specifying that the T and Z can also be lowercase. As far as I’m aware, the only difference between the two is something related to the - in the time zone offset... though I’ve also seen plenty of libraries parse 8601 with and without -, so it seems not to be super important.

d0mine 6y ago
rfc3339 is a profile of iso8601 i.e., every rfc3339 date is also iso8601 date but not in reverse
- chrismeller 6y ago
  Do you have an example of an 8601 that is not 3339 compliant? I’ve never looked at any of the abbreviated formats, but if you’re giving a full date, time, and offset it seems identical (aside from that -).
  - ncallaway 6y ago
    Sure! 2021-W07-5
    - deleted 6y ago
      [deleted]
    - chrismeller 6y ago
      Ahh, you got me. I thought I had mentioned that I had never looked at any of the formats for shorter than full date, time, and offset strings. D’oh!
      - ncallaway 6y ago
        I'm _fairly_ sure that 2021-W07-5T00:00:00Z or 2000-W03-7T01:23:45.678+09:00 would be a valid full ISO date time and offset as well, but I haven't checked the specification. Luxon will happily parse 2021-W07-5T00:00:00Z and tell me that it represents 2021-02-18T16:00:00.000-08:00, so I think it's valid.
  - Darkphibre 6y ago
    "Funny" story about a binary 8601 implementation. I was architecting a true-realtime telemetry pipeline for a AAA videogame studio (later used by a dozen or so franchises for all titles by the publisher). It had a requirement for subsecond client notification of per-user aggregated statistics, including complicated event interactions (such as ensuring the grenade that you threw that killed someone, would only be attributed to you if a prior event hadn't already occured), which resulted in sequentiality guarantees. But with that, we could get rid of windowed event processing (and those inherent latencies), and instead treat them as a true stream of events. Keep in mind we could support up to 400ms one-way latency, so we only had 200ms for processing/routing in the client and in the cloud. I measured client code in μs. Annnyways. The principal in our org insisted that time not be be transmitted as an epoch. I argued for weeks, but he was insistent... "No magical offsets to arbitrary dates. ISO8601. Do it." He came from and worked most heavily with the web services group. Apparently some point in the past, services had picked the wrong epoch and there was confusion (I still can't understand how that wouldn't be caught right away, there's only a few standard epochs that are quite different in resulting time)? The events in my design were bit-packed using a competing protocol to Protocol Buffers... there's no way I was doubling the payloads just to store a timestamp as a string. So I read and re-read ISO8601. And it dawned on me: ISO-8601 never specifies the encoding. It specifies the order in which information is conveyed, and if in text, the delimiters to use. One example clue is in the definition of basic format, and the call-out that most of the document leverages plain text to communicate their ideas. basic format format of a date and time representation or date and time format representation comprising the minimum number of time elements necessary for the accuracy required. The basic format should be avoided in plain text. I ended up proposing the most terrible hack I've had to live with. It involved bit-packed 64-bit integer that stored: 12 bits for year, 4 bits for month, 5 bits for date, 5 bits for hours, 6 bits for minutes, 6 bits for seconds, and the remaining bits for an integer that stores the sub-second fraction. We lost a few orders of magnitude resolution on that end due to the inefficiencies of the earlier packing, but... it worked. And it was in the right order. And there were no "magic" epochs to dissuade the principal engineer. Most importantly, it sailed through the review process. Still makes my skin crawl a decade later. And I secretly suspect you technically have to have a T between date and time to be ISO8601 compliant, it's been a long while since I read the spec. But there you go.
  - andoriyu 6y ago
    Sure, `20201209T160953Z` or 2021-123.
- seagreen 6y ago
  This gets repeated a lot but unfortunately isn't true. See the spec: https://tools.ietf.org/html/rfc3339 https://tools.ietf.org/html/rfc3339 NOTE: ISO 8601 defines date and time separated by "T". Applications using this syntax may choose, for the sake of readability, to specify a full-date and full-time separated by (say) a space character. Someday someone reading this is going to set out to make a new, small specification out of a huge specification. Reader, when you start to feel the temptation to make just the tiniest improvement-- resist! It's way more useful if it's actually a true subset. Happily this particular issue is be easily fixed. Let's make a new spec, subsetting both ISO 8601 and RFC 3339. I hereby introduce... RFC 3339T, which is exactly like RFC 3339, but you have to use a T instead of a space. EDIT: joshuaissac spotted another difference. Also I made a repo so we're official: https://github.com/seagreen/rfc-3339T https://github.com/seagreen/rfc-3339T
  - joshuaissac 6y ago
    RFC 3339 also allows the offset -00:00 where the UTC time is known but the local time is not. The ISO standard does not permit this.
    - seagreen 6y ago
      Ooh, interesting. I made a GitHub repo for the new spec and credited you (https://github.com/seagreen/rfc-3339T https://github.com/seagreen/rfc-3339T). Let me know if you have more suggestions!
    - fanf2 6y ago
      -00:00 is permitted by ISO 8601 but it implies that the local time is the same as UTC, it does not imply that the local time is unknown.
      - seagreen 6y ago
        Is Wikipedia wrong? It claims (https://en.wikipedia.org/wiki/ISO_8601 https://en.wikipedia.org/wiki/ISO_8601): An offset of zero, in addition to having the special representation "Z", can also be stated numerically as "+00:00", "+0000", or "+00". However, it is not permitted to state it numerically with a negative sign, as "−00:00", "−0000", or "−00"." Sure would be nice if we could read the spec online:)