I don't think I realized how many alternative formats there are for both 3339 and 8601. Most of those alternative formats are redundant. I like that this chart shows the venn diagram of where these standards intersect.
mg · 1h ago
My favorite datetime format is "YYYY-MM-DD hh:mm:ss".
I consider it the "Markdown for time". It is human-friendly and computer-friendly at the same time. It is supported by many languages and databases. It is so elegant and common that even though it is not part of a standard, LLMs started to use it when writing answers:
It is not computer-friendly because the timezone is unspecified. And in some timezones, it is ambiguous during changes from DST to winter time.
nine_k · 8m ago
Fair. But the point is that it follows the only reasonable order, consistently from larger units to smaller.
A datetime can be seen as a number written in a positional notation, just with varying base: divmod by 60, 60, 24, 12. When you pick a normal decimal / hex / binary number, you expect that the digits in it come in the order of magnitude changing: thousands, hundreds, tens, ones. Mixing them would feel crazy. By the same token, formats like dd-mm-yyyy HH:MM or mm-dd-yyyy are crazy; sadly they are traditional.
Why is it not computer friendly? It's just a local time. This is something we need to be able to express in computers and in brains.
Things like opening hours or appointment times are always local time, and even if Apple disagrees I very strongly believe that alarm clocks should use local time as well.
rocqua · 10m ago
Looking through the original article, this date format is only available in the RFC, and then only with the Z (which makes it UTC).
Is there a timezoned version of this that is standardized?
mg · 33m ago
Do you really need the timezone for each entry in the storage layer?
The application knows how it stores data, so it can just use UTC or whatever it likes. One timezone for all entries.
The interface then can display it in a way the user likes.
NAR8789 · 13m ago
This sounds like a footgun.
At some point some application developer will introduce a bug where they're not sending utc.
Without the time zone, the wrong times will end up in the database, bad data mixed in with good. This will be a nightmare to fix.
With the time zone, I don't think this class of bugs is possible. Most application developers will wrap the time in an object that allows them to do time operations without needing to directly handle time zone in most cases.
nine_k · 17m ago
From bitter experience: yes, having TZ-aware dates and times everywhere is helpful, and saves you more in (lack of) trouble than it costs in storage and "hassle".
LukeShu · 50m ago
Except for not including a timezone offset, that's one of the RFC 3339 formats.
I consider it the "Markdown for time". It is human-friendly and computer-friendly at the same time. It is supported by many languages and databases. It is so elegant and common that even though it is not part of a standard, LLMs started to use it when writing answers:
Me: SQLite: Add 1 day and 3 hours to a date.
Perplexity: SELECT DATETIME('2025-09-07 07:51:00', '+1 day', '+3 hours');
A datetime can be seen as a number written in a positional notation, just with varying base: divmod by 60, 60, 24, 12. When you pick a normal decimal / hex / binary number, you expect that the digits in it come in the order of magnitude changing: thousands, hundreds, tens, ones. Mixing them would feel crazy. By the same token, formats like dd-mm-yyyy HH:MM or mm-dd-yyyy are crazy; sadly they are traditional.
Things like opening hours or appointment times are always local time, and even if Apple disagrees I very strongly believe that alarm clocks should use local time as well.
Is there a timezoned version of this that is standardized?
The application knows how it stores data, so it can just use UTC or whatever it likes. One timezone for all entries.
The interface then can display it in a way the user likes.
At some point some application developer will introduce a bug where they're not sending utc.
Without the time zone, the wrong times will end up in the database, bad data mixed in with good. This will be a nightmare to fix.
With the time zone, I don't think this class of bugs is possible. Most application developers will wrap the time in an object that allows them to do time operations without needing to directly handle time zone in most cases.
[0] https://stackoverflow.com/a/58633651