5 ms·

no time zones on date/&times? they should be added.

gregordv 4y ago
Especially on the timestamps, I find some of the design choices a little bit bizarre. Choosing only a strict ISO8601 format: awesome! Choosing to excise critical parts (representing timezones and fractional seconds): very unfortunate. Chesterson's Fence (https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence) https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_... is a very powerful design principle. They chose to put those elements into ISO 8601 for principled reasons: they come from pain. They embody responses to mistakes that I've made, and thousands of other engineers before me. Unless we fully understand the reason they were included, don't arbitrarily to do "I haven't used it, so it must be useless." Other than that, it looks like a clean spec, but I'm not personally convinced that it has enough incremental value over JSON or YAML to replace them in the human-readable exchange format space. It can be a little more concise, but if I'm making something for humans, clarity (typically) has more value than conciseness. Are there other compelling values that I'm missing?
- jonhohle 4y ago
  Amazon’s Ion[0] uses ISO 8601 including fractional seconds and offsets as its date time format. 0 - https://amzn.github.io/ion-docs/ https://amzn.github.io/ion-docs/
nmz 4y ago
No time zones ever. If I see a date and its X, I know that I only need to add y to get my timezone to know when this happened. but if anybody puts a timezone there, now I can't do it mentally.
- kgwxd 4y ago
  What timezone do you assume the source datetime is in?
  - 9dev 4y ago
    UTC, of course: the only sensible timezone to store date and time in.
    - 0x20cowboy 4y ago
      Until everyone starts using stardate or something similar :)
      - nmz 4y ago
        GPS
    - zaphirplane 4y ago
      The response that always comes up is “at 9am” in a TZ with DST, Doesn’t work with UTC
  - dexterdog 4y ago
    If you're most Americans, EST. If you're Apple, PST. If you're a technical person, UTC.
  - AndrewDucker 4y ago
    UTC
  - chrismorgan 4y ago
    Since there are three incorrect responses to this comment already: Anyone saying “UTC” is wrong. Unambiguously wrong if offsets are supported, and in foolish contexts like this where offsets are not supported, still wrong due to common sense and custom. If there is no offset, there is no offset. It’s what is commonly called a naive or plain datetime. How it should be interpreted is explicitly undefined if offset-capable, and implicitly undefined by strong custom if not offset-capable; but it will generally mean in the local time zone, whatever that is—and it could be relative to a particular machine or a particular user. This is often suitable for social use, but completely unsuitable for machine history-recording use. So: the question is rhetorical, unanswerable, thereby demonstrating why nmz’s position is unreasonable. (Actually, only probably unreasonable because nmz’s wording wording with its “X” and “y” is not clear and may be using the term “timezone” subtly—the trouble is it’s used to mean three different things: firstly and most properly, a name for a set of rules about which time offsets to use when, e.g. “Australian Eastern Time” or “Australia/Melbourne” as it’s called in the IANA Time Zone Database, which roughly means AEST (+10:00) for half the year and AEDT (+11:00) for the other half, but conveys the rules as they have been through time; secondly, a somewhat less correct colloquial usage, a named time offset, e.g. “AEDT” or “Australian Eastern Daylight Saving Time” for +11:00; and thirdly, fairly clearly into the realm of misuse but still very common, a time offset like “+11:00”. If nmz was using the term “timezone” more precisely to mean one of the named concepts and expressly not an offset, then yeah, times written that way do require memorising a whole database, whereas offsets are straightforward to calculate, though it’s definitely harder having to do two calculations than the just one if it starts at UTC.)
chrismorgan 4y ago
Does seem a surprising omission. I’d expect offset support, and like more recent fancier draft stuff from https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-extended-06.html https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-e..., Internet Extended Date/Time Format, where you can specify a named time zone rather than just an offset.
bloak 4y ago
Yes, and some people need to use TAI instead of UTC.

Especially on the timestamps, I find some of the design choices a little bit bizarre. Choosing only a strict ISO8601 format: awesome! Choosing to excise critical parts (representing timezones and fractional seconds): very unfortunate. Chesterson's Fence (https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence) https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_... is a very powerful design principle. They chose to put those elements into ISO 8601 for principled reasons: they come from pain. They embody responses to mistakes that I've made, and thousands of other engineers before me. Unless we fully understand the reason they were included, don't arbitrarily to do "I haven't used it, so it must be useless." Other than that, it looks like a clean spec, but I'm not personally convinced that it has enough incremental value over JSON or YAML to replace them in the human-readable exchange format space. It can be a little more concise, but if I'm making something for humans, clarity (typically) has more value than conciseness. Are there other compelling values that I'm missing?

jonhohle 4y ago
Amazon’s Ion[0] uses ISO 8601 including fractional seconds and offsets as its date time format. 0 - https://amzn.github.io/ion-docs/ https://amzn.github.io/ion-docs/

nmz 4y ago

No time zones ever. If I see a date and its X, I know that I only need to add y to get my timezone to know when this happened. but if anybody puts a timezone there, now I can't do it mentally.

kgwxd 4y ago
What timezone do you assume the source datetime is in?
- 9dev 4y ago
  UTC, of course: the only sensible timezone to store date and time in.
  - 0x20cowboy 4y ago
    Until everyone starts using stardate or something similar :)
    - nmz 4y ago
      GPS
  - zaphirplane 4y ago
    The response that always comes up is “at 9am” in a TZ with DST, Doesn’t work with UTC
- dexterdog 4y ago
  If you're most Americans, EST. If you're Apple, PST. If you're a technical person, UTC.
- AndrewDucker 4y ago
  UTC
- chrismorgan 4y ago
  Since there are three incorrect responses to this comment already: Anyone saying “UTC” is wrong. Unambiguously wrong if offsets are supported, and in foolish contexts like this where offsets are not supported, still wrong due to common sense and custom. If there is no offset, there is no offset. It’s what is commonly called a naive or plain datetime. How it should be interpreted is explicitly undefined if offset-capable, and implicitly undefined by strong custom if not offset-capable; but it will generally mean in the local time zone, whatever that is—and it could be relative to a particular machine or a particular user. This is often suitable for social use, but completely unsuitable for machine history-recording use. So: the question is rhetorical, unanswerable, thereby demonstrating why nmz’s position is unreasonable. (Actually, only probably unreasonable because nmz’s wording wording with its “X” and “y” is not clear and may be using the term “timezone” subtly—the trouble is it’s used to mean three different things: firstly and most properly, a name for a set of rules about which time offsets to use when, e.g. “Australian Eastern Time” or “Australia/Melbourne” as it’s called in the IANA Time Zone Database, which roughly means AEST (+10:00) for half the year and AEDT (+11:00) for the other half, but conveys the rules as they have been through time; secondly, a somewhat less correct colloquial usage, a named time offset, e.g. “AEDT” or “Australian Eastern Daylight Saving Time” for +11:00; and thirdly, fairly clearly into the realm of misuse but still very common, a time offset like “+11:00”. If nmz was using the term “timezone” more precisely to mean one of the named concepts and expressly not an offset, then yeah, times written that way do require memorising a whole database, whereas offsets are straightforward to calculate, though it’s definitely harder having to do two calculations than the just one if it starts at UTC.)

chrismorgan 4y ago

Does seem a surprising omission. I’d expect offset support, and like more recent fancier draft stuff from https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-extended-06.html https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-e..., Internet Extended Date/Time Format, where you can specify a named time zone rather than just an offset.

bloak 4y ago

Yes, and some people need to use TAI instead of UTC.