5 ms·

Why would one prefer ISO 8601 dates over POSIX timestamps?

by drdrey 5y ago

paulryanrogers 5y ago
Human readability most likely
mulmboy 5y ago
They can include a local timezone. Sometimes there's a big difference between 12am in UTC+0 and 3am in UTC+3 despite representing the same instant in time.
- inopinatus 5y ago
  True enough, but I would still recommend that API responses normalize to UTC (Z suffix) in the general case and document as much, and if actually returning a timestamp with a specific timezone, document the intended meaning.
  - guhidalg 5y ago
    +1, if your application cares about time then you should just tell your users all dates will be normalized to UTC and they are responsible for displaying them in a preferred time zone.
    - codebje 5y ago
      Time zone rules change relatively frequently - future dates may be better stored in the appropriate time zone, optionally along with the UTC offset at the time of recording, so you don't report incorrect information when the rules do change on you. Past dates should always be in UTC, for the same reason - timezone rule changes are sometimes even retroactive.
hn_throwaway_99 5y ago
1. Human readability 2. The ISO date format is "big endian" by default, which makes it trivial to chunk and compare just specific date parts. Want all events that occurred on the same (UTC) date? Just do dateField.substring(0, 10). Everything in the same year? dateField.substring(0, 4).
seelmobile 5y ago
I prefer them because they're human readable and can preserve time zones if that's important
djbusby 5y ago
8601 has a large pattern space - RFC 3339 is a narrower subset of ISO. Somewhere I saw a diagram that convinced me. I link if I can find again. Edit: a relevant link https://news.ycombinator.com/item?id=28976526 https://news.ycombinator.com/item?id=28976526
- worik 5y ago
  https://ijmacd.github.io/rfc3339-iso8601/ https://ijmacd.github.io/rfc3339-iso8601/ A ven diagram very cool
  - djbusby 5y ago
    That's the one! Thanks!
inopinatus 5y ago
* Human readable * Supports birthdays for people older than 52 * Reliable after 2038 * Supports leap seconds * HTML date/time spec is a subset * String collation order matches temporal order * Excel
- latch 5y ago
  > * Human readable Computers are the main consumers of APIs, and ISO 8601 is far from machine-readable. For example, in Elixir, DateTime.from_iso8601/1 won't recognize "2022-03-12T07:36:08" even though it's valid. I had to rewrite a chunk of Python's radidjson wrapper to 1-9 digit fractional seconds (1). I'm willing to bet 99% of ISO8601 will fail to handle all aspects of the spec. So when you say "ISO8601" what you're really saying is "our [probably undocumented, and possibly different depending on what system you're hitting] version of the ISO-86001 spec." (1) https://github.com/python-rapidjson/python-rapidjson/pull/133/files https://github.com/python-rapidjson/python-rapidjson/pull/13...
  - inopinatus 5y ago
    > what you're really saying No. The specific profile of ISO8601 that should be used to express timestamps in an API is that defined in RFC3339. Choosing to use a half-baked parser is a separate matter.

Why would one prefer ISO 8601 dates over POSIX timestamps?

by drdrey 5y ago

Why would one prefer ISO 8601 dates over POSIX timestamps?

paulryanrogers 5y ago

Human readability most likely

mulmboy 5y ago

They can include a local timezone. Sometimes there's a big difference between 12am in UTC+0 and 3am in UTC+3 despite representing the same instant in time.

inopinatus 5y ago
True enough, but I would still recommend that API responses normalize to UTC (Z suffix) in the general case and document as much, and if actually returning a timestamp with a specific timezone, document the intended meaning.
- guhidalg 5y ago
  +1, if your application cares about time then you should just tell your users all dates will be normalized to UTC and they are responsible for displaying them in a preferred time zone.
  - codebje 5y ago
    Time zone rules change relatively frequently - future dates may be better stored in the appropriate time zone, optionally along with the UTC offset at the time of recording, so you don't report incorrect information when the rules do change on you. Past dates should always be in UTC, for the same reason - timezone rule changes are sometimes even retroactive.

hn_throwaway_99 5y ago

1. Human readability 2. The ISO date format is "big endian" by default, which makes it trivial to chunk and compare just specific date parts. Want all events that occurred on the same (UTC) date? Just do dateField.substring(0, 10). Everything in the same year? dateField.substring(0, 4).

seelmobile 5y ago

I prefer them because they're human readable and can preserve time zones if that's important

djbusby 5y ago

8601 has a large pattern space - RFC 3339 is a narrower subset of ISO. Somewhere I saw a diagram that convinced me. I link if I can find again. Edit: a relevant link https://news.ycombinator.com/item?id=28976526 https://news.ycombinator.com/item?id=28976526

worik 5y ago
https://ijmacd.github.io/rfc3339-iso8601/ https://ijmacd.github.io/rfc3339-iso8601/ A ven diagram very cool
- djbusby 5y ago
  That's the one! Thanks!

inopinatus 5y ago

* Human readable * Supports birthdays for people older than 52 * Reliable after 2038 * Supports leap seconds * HTML date/time spec is a subset * String collation order matches temporal order * Excel

latch 5y ago
> * Human readable Computers are the main consumers of APIs, and ISO 8601 is far from machine-readable. For example, in Elixir, DateTime.from_iso8601/1 won't recognize "2022-03-12T07:36:08" even though it's valid. I had to rewrite a chunk of Python's radidjson wrapper to 1-9 digit fractional seconds (1). I'm willing to bet 99% of ISO8601 will fail to handle all aspects of the spec. So when you say "ISO8601" what you're really saying is "our [probably undocumented, and possibly different depending on what system you're hitting] version of the ISO-86001 spec." (1) https://github.com/python-rapidjson/python-rapidjson/pull/133/files https://github.com/python-rapidjson/python-rapidjson/pull/13...
- inopinatus 5y ago
  > what you're really saying No. The specific profile of ISO8601 that should be used to express timestamps in an API is that defined in RFC3339. Choosing to use a half-baked parser is a separate matter.