7 ms·

So? I'd be happy if people would consistently use RFC 3339 (https://tools.ietf.org/html/rfc3339 https://tools.ietf.org/html/rfc3339). This will solve 99.999% yo

So? I'd be happy if people would consistently use RFC 3339 (https://tools.ietf.org/html/rfc3339 https://tools.ietf.org/html/rfc3339). This will solve 99.999% you're going to run across. If you're part of that 0.001% who actually needs the standard - then it will be worth a few bucks to obtain it.

Macha 6y ago
Yeah, there's enough software that only understands ISO-8601 to be YYYY-MM-DDThh:mm:ss (with optional Z or +/-xx:xx for a offset datetime), that I wouldn't rely on anything more niche from the spec. That does include the period definition format, which I know will disappoint some people.
- taylodl 6y ago
  > period definition format You mean the milliseconds? You're correct that YMMV with regards to libraries, but a lot of them handle milliseconds as well.
  - Macha 6y ago
    No, I mean stuff like 2007-03-01T13:00:00Z/P1M For something that occurs on the first of each month.
    - taylodl 6y ago
      Oh - combining a date/timestamp and a duration, such as xsd:duration (http://www.datypic.com/sc/xsd/t-xsd_duration.html http://www.datypic.com/sc/xsd/t-xsd_duration.html). I've never seen them combined into a single string, though there have been times when that would have been really useful!
      - em500 6y ago
        It looks like xsd:duration uses duration notation from ISO8601. The rules for combining them or designating recurring intervals are in ISO8601 section 4.4-4.5 [1]. Unfortunately, awareness and library support for ISO8601 interval notation are very sparse and most people/orgs just roll their own. [1] https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_iso_wd_8601-1_2016-02-16.pdf https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_i...
    - phendrenad2 6y ago
      Yeah I didn't know that ISO had recurring events in the spec. I guess most library authors don't either, and as GP said, they think the RFC covers it.
- Quekid5 6y ago
  After learning some more about the practicalities of time/date throughout my career, it always seemed a bit odd to me to even support the +/- thing... but maybe I'm missing something. My reasoning is: If it's a timestamp (i.e. it's a point on the physical time line, relativity notwithstanding), Z should be fine and unambiguous. If it's a local date/time then you need the actual legal time zone (e.g. Europe/Berlin, or whatever.) since those can and have changed historically. Sure, you can encode that as an offset for any given instant if you're actually talking about "now" or the past, but that's a lossy encoding and you can't really talk about future events using an offset.
  - rntksi 6y ago
    My understanding is that it is because it changes historically that you'd rather want +/- (an absolute measure) rather than Continent/Location denonimation (a measure that is bound to change). If you want to record a local timestamp historically (e.g. log that this event of the electric facility happened at this time in the history of the facility, at the location of the facility), you want to say exactly when it happened, in the local time of the place, notwithstanding political/societal changes to the timezone it is attached to. Does this make sense? Talking about time always makes things confusing.
    - Quekid5 6y ago
      Right, for explicitly recording a timestamp without having to refer to a historical time zone database it would seem to make a tiny bit of sense... but recording the actual time zone would work just as well for historical data and future times. I just have a hard time imagining a scenario where you really care about the offset... the timestamp itself is enough. Maybe it's just historical baggage from not wanting to keep that historical record of time zones around for all eternity? I dunno. It's a bit weird to me. It's a very indirect (precise) measure of something that doesn't seem like it would have much use over just recording the direct measure (TZ and/or just the UTC timestamp) The more your learn about datetime the more confusing it gets, I suppose :). I guess it's good to know that it can get very confusing (and therefore to tread carefully) and to temper one's expectations of datetime libraries.
Someone1234 6y ago
In my experience when people refer to ISO-8601, they generally mean RFC 3339 instead anyway. The original ISO has some very niche stuff in it people have no interest in supporting. Whereas 3339 is pretty much just the bread and butter of the format.
pistolpeteDK 6y ago
In my experience (as a European) I found that RFC3339 was lacking a few things when it comes to software development; especially the usage of 24:00 to mark midnight at the end of a day; which is a valid value according to ISO8601(can't remember the section).
- taylodl 6y ago
  I work for a utility who often needs to work with interval data. The last interval of the day is 23:00-24:00 whereas the first interval of the day is 00:00-01:00. Some libraries can handle that as you'd expect, others can't. A lot of people are surprised to see 24:00. The key is 24:00 is the same date as 23:00, whereas 00:00 is the next day. It sounds like you have a similar need?
  - bloak 6y ago
    In railway timetables things like 24:37 are sometimes used, for example for a train that leaves at 23:45 and arrives at 24:37 on weekdays. It would not just be confusing but totally incorrect to claim that the train arrives at 00:37 on weekdays. On the other hand, I don't think I've ever seen a 25:xx, and if you were writing a timetable for a slow train on the Trans-Siberian Railway then I really don't think people would appreciate it if you used a three-digit hour.
    - the_imp 6y ago
      I've seen 25:00 and even 26:00 being used as times, in Japan.
      - earthboundkid 6y ago
        I have also seen 24+ in Japan.
      - kalleboo 6y ago
        Yes they are common in Japan for stuff like store opening hours and TV time tables
jedimastert 6y ago
Would https://tools.ietf.org/html/rfc3339#appendix-A https://tools.ietf.org/html/rfc3339#appendix-A be copyright infringement?

Macha 6y ago

Yeah, there's enough software that only understands ISO-8601 to be YYYY-MM-DDThh:mm:ss (with optional Z or +/-xx:xx for a offset datetime), that I wouldn't rely on anything more niche from the spec. That does include the period definition format, which I know will disappoint some people.

taylodl 6y ago
> period definition format You mean the milliseconds? You're correct that YMMV with regards to libraries, but a lot of them handle milliseconds as well.
- Macha 6y ago
  No, I mean stuff like 2007-03-01T13:00:00Z/P1M For something that occurs on the first of each month.
  - taylodl 6y ago
    Oh - combining a date/timestamp and a duration, such as xsd:duration (http://www.datypic.com/sc/xsd/t-xsd_duration.html http://www.datypic.com/sc/xsd/t-xsd_duration.html). I've never seen them combined into a single string, though there have been times when that would have been really useful!
    - em500 6y ago
      It looks like xsd:duration uses duration notation from ISO8601. The rules for combining them or designating recurring intervals are in ISO8601 section 4.4-4.5 [1]. Unfortunately, awareness and library support for ISO8601 interval notation are very sparse and most people/orgs just roll their own. [1] https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_iso_wd_8601-1_2016-02-16.pdf https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_i...
  - phendrenad2 6y ago
    Yeah I didn't know that ISO had recurring events in the spec. I guess most library authors don't either, and as GP said, they think the RFC covers it.
Quekid5 6y ago
After learning some more about the practicalities of time/date throughout my career, it always seemed a bit odd to me to even support the +/- thing... but maybe I'm missing something. My reasoning is: If it's a timestamp (i.e. it's a point on the physical time line, relativity notwithstanding), Z should be fine and unambiguous. If it's a local date/time then you need the actual legal time zone (e.g. Europe/Berlin, or whatever.) since those can and have changed historically. Sure, you can encode that as an offset for any given instant if you're actually talking about "now" or the past, but that's a lossy encoding and you can't really talk about future events using an offset.
- rntksi 6y ago
  My understanding is that it is because it changes historically that you'd rather want +/- (an absolute measure) rather than Continent/Location denonimation (a measure that is bound to change). If you want to record a local timestamp historically (e.g. log that this event of the electric facility happened at this time in the history of the facility, at the location of the facility), you want to say exactly when it happened, in the local time of the place, notwithstanding political/societal changes to the timezone it is attached to. Does this make sense? Talking about time always makes things confusing.
  - Quekid5 6y ago
    Right, for explicitly recording a timestamp without having to refer to a historical time zone database it would seem to make a tiny bit of sense... but recording the actual time zone would work just as well for historical data and future times. I just have a hard time imagining a scenario where you really care about the offset... the timestamp itself is enough. Maybe it's just historical baggage from not wanting to keep that historical record of time zones around for all eternity? I dunno. It's a bit weird to me. It's a very indirect (precise) measure of something that doesn't seem like it would have much use over just recording the direct measure (TZ and/or just the UTC timestamp) The more your learn about datetime the more confusing it gets, I suppose :). I guess it's good to know that it can get very confusing (and therefore to tread carefully) and to temper one's expectations of datetime libraries.

Someone1234 6y ago

In my experience when people refer to ISO-8601, they generally mean RFC 3339 instead anyway. The original ISO has some very niche stuff in it people have no interest in supporting. Whereas 3339 is pretty much just the bread and butter of the format.

pistolpeteDK 6y ago

In my experience (as a European) I found that RFC3339 was lacking a few things when it comes to software development; especially the usage of 24:00 to mark midnight at the end of a day; which is a valid value according to ISO8601(can't remember the section).

taylodl 6y ago
I work for a utility who often needs to work with interval data. The last interval of the day is 23:00-24:00 whereas the first interval of the day is 00:00-01:00. Some libraries can handle that as you'd expect, others can't. A lot of people are surprised to see 24:00. The key is 24:00 is the same date as 23:00, whereas 00:00 is the next day. It sounds like you have a similar need?
- bloak 6y ago
  In railway timetables things like 24:37 are sometimes used, for example for a train that leaves at 23:45 and arrives at 24:37 on weekdays. It would not just be confusing but totally incorrect to claim that the train arrives at 00:37 on weekdays. On the other hand, I don't think I've ever seen a 25:xx, and if you were writing a timetable for a slow train on the Trans-Siberian Railway then I really don't think people would appreciate it if you used a three-digit hour.
  - the_imp 6y ago
    I've seen 25:00 and even 26:00 being used as times, in Japan.
    - earthboundkid 6y ago
      I have also seen 24+ in Japan.
    - kalleboo 6y ago
      Yes they are common in Japan for stuff like store opening hours and TV time tables

jedimastert 6y ago

Would https://tools.ietf.org/html/rfc3339#appendix-A https://tools.ietf.org/html/rfc3339#appendix-A be copyright infringement?