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:
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.
danlitt · 57m ago
If local time is qualified with where "local" is then it is identical to using a time with a locale, like Europe/London or whatever. Unqualified local time is wrong/confusing the moment you have any requirement which crosses a time zone (which happens when you wouldn't expect it, that's the whole reason people care about this problem).
Even your example of alarms is not obvious. If you set a timer, or a daily alarm to wake up by, then yes. But if you set an alarm for some event, like sunrise for example, then you would need a zone.
fauigerzigerk · 10m ago
>If local time is qualified with where "local" is then it is identical to using a time with a locale, like Europe/London or whatever
We may not know the location when we write down a datetime. It could be "wherever I may be at the time".
Even if we do know the location, we cannot know for sure what point in time a future local time refers to because locations can change timezones.
>Even your example of alarms is not obvious. If you set a timer, or a daily alarm to wake up by, then yes. But if you set an alarm for some event, like sunrise for example, then you would need a zone.
That's absolutely right. We need to be able to store points in time and we need to be able to store local times that are relative to locations that are yet to be determined and relative to as yet unknown timezones. The two concepts cannot be merged.
pasc1878 · 2h ago
Well is it a local time or not. If it is a local time where is it a local time?
You need a timezone as well.
fauigerzigerk · 1h ago
No, I think it's very important to understand that local times in the future do not identify a point in time and that local times are not necessarily tied to any particular location.
If I set my alarm clock to 7am, I want it to always wake me at 7am local time regardless of where I happen to be on that day.
If I make an appointment for 7 Sep 2026 at 3pm I'm going to turn up at whatever time counts as 3pm on that date. The government might scrap DST, so the exact point in time is currently unknown.
Many uses of local time cannot be expressed correctly if you are forced to specify a timezone.
rendaw · 1h ago
You wouldn't use a datetime for an alarm clock, just a time.
The timezone is implicit in the appointment, it's the timezone of the place you're making the appointment at.
Scrapping DST is built into the timezone database IIRC, as are other timezone shifts.
In the SQL example way above, the database is probably assuming UTC, which would make the datetime math give incorrect results (ex: around dst changes) if you interpreted it naively as a local time.
This feels like a very Chesterton's Fence thread.
fauigerzigerk · 58m ago
>The timezone is implicit in the appointment, it's the timezone of the place you're making the appointment at.
Yes, but we cannot know which timezone that will be or how it will be defined and therefore we cannot store this appointment as a point in time.
This is what we're talking about, right? Can we store all datetimes as points in time or not? I'm convinced that we cannot always do that because there are datetime semantics that cannot be expressed in that way.
[Edit]
>You wouldn't use a datetime for an alarm clock, just a time
You should tell Apple that. They somehow managed to get this wrong. And I suspect the reason may be that many developers really really want all (date)time specifications to be points in time. They are not.
frizlab · 16m ago
I don’t know what’s your beef against Apple but the alarm clock does use a local time (though there have been (unacceptable) bugs leading to incorrect wake up time due to DST).
mattclarkdotnet · 22m ago
Of course you want to be able to say 03:00 Europe/London for calendar appointments. Which it is true is not a timezone, and needs to be stored separately from the date time identifier…
bakje · 1h ago
This is true when using a UTC offset as it has any potential DST already applied, so it can’t adapt to changes like that.
But if you say I have an appointment at 2026-09-07 15:00:00 in the timezone America/New_York I think that also accounts for future rule changes of that timezone.
I’m no expert on this matter but I believe that’s similar to how the new JS temporal API handles such things
fauigerzigerk · 1h ago
If the definition of timezone names can change, then the combination of a future datetime and a timezone name does not identify a point in time.
Also, what if I don't know yet where I will be and I want to set a reminder for a particular date and time?
cwillu · 1h ago
If I set my cellphone alarm to go off at 6am, and it goes off at 8am instead “because it's currently 6am in new york”, the alarm clock fucked up.
bloak · 1h ago
Unless New York gets split into two, Berlin-style, and the parts have different time zones.
mcny · 54m ago
Should it ring twice if you go across the border one way? Should it not ring if you go across the border the other way?
oasisaimlessly · 14m ago
Yes? Same could be said right now for setting an alarm during the hour skipped/repeated by a DST transition.
OskarS · 1h ago
> No, I think it's very important to understand that local times in the future do not identify a point in time and that local times are not necessarily tied to any particular location.
I mean, they sometimes do. You might want to wake up at 7.00 AM in the morning regardless of what timezone you’re in, but if I ask Siri what time sunrise is tomorrow (very relevant for setting my alarm!) she better give it to me in local time taking time zones into account.
Another example: I’ve added all the F1 races and qualifications this year to my calendar (I’m a big fan) so I can easily check that the Italian Grand Prix at Monza starts today at 3.00 PM my local time. If I travel to another timezone, my calendar better adjust, or else I’ll miss the races.
fauigerzigerk · 1h ago
That's my whole point really. We need both points in time and (date)times that are relative to some possibly unknown location. These concepts cannot be merged.
tsimionescu · 2h ago
A local time is not tied to a timezone. When I set my wake up alarm at 8:30 every day, it should stay at 8:30 regardless of the current timezone. If I travel to the USA, my phone shouldn't start waking me up at 22:30.
bsaul · 1h ago
The datetime mentionned in parent post had both a date and a time component, which has the meaning of a "point in time". Not just a "time". Point in time needs location information to guess the timezone, otherwise you simply can't make anything out of it.
Your definition would have been just storing "hh:mm:ss".
tsimionescu · 27m ago
That's a good point, I hadn't thought of that part. Local times can make sense, but datetimes really should always have a location timezone associated.
ivan_gammel · 1h ago
You are right that LocalDateTime requires location, but it is not part of the data type and data format. It’s just date and time without timezone and location is stored separately.
fauigerzigerk · 1h ago
>You are right that LocalDateTime requires location
No. If I set a reminder for a particular date and time in the future, I want it to go off at that local date and time wherever I may be.
The location cannot be part of the data type because "local" is sometimes relative to movable objects.
bsaul · 1h ago
good point, never thought of that.
shmerl · 1h ago
Local time is irrelevant when you present that time to someone else external. How would they know what your local timezone is? This presentation tells them nothing about it.
So it's good for local use, but inadequate for any use that's not tied to your local environment. Alarms and etc. are already using it, so it's not about that use case.
Ekaros · 54m ago
Local time to where?
There is even more fun corner cases. Say you live at border of timezone. First have a meeting at 12:00 for 45 minutes in one zone, then move westward and now have an other meeting at 12:00. How do you mark these in calendar? Communicate them? Make historical log?
SideburnsOfDoom · 24m ago
> It's just a local time.
It's potentially a local time, potentially not. It's unspecified and that will cause trouble.
If you want to model "stores open at 8:30am, worldwide" then there are data types for that "time only". They are not "date and time".
hdgvhicv · 1h ago
2025-11-02 01:30:00 in New York.
When does that happen.
nine_k · 2h 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.
rocqua · 2h 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?
dijit · 1h ago
the number after the Z is the offset to UTC.
2025-09-07 10:57:00Z+2 would be CEST for example. (+2 hours ahead).
2025-09-07 04:57:00Z-4 would be EDT (4 hours behind UTC)
isbvhodnvemrwvn · 1h ago
Offset is not the same as a timezone. Offsets change throughout the year in the same geographic areas (or don't or both do and don't)
dijit · 1h ago
No, timezones don’t change but they are swapped out by countries, offsets and timezones are an n:1 mapping. Multiple timezones represent the same offset, but those offsets are immutable.
CEST will always be +2 UTC (unless something really changes politically).
DST just marks that Sweden changes from CEST to CET from October to May. So Swedens offset changes, but the timezone does not change its offset.
KronisLV · 1h ago
At that point, just give me
2025-09-07T11:30:31.304[Europe/Riga]
the machine can figure out the current offset and GMT itself because in any given time in the year I have no idea without looking it up.
mg · 2h 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.
procaryote · 2h ago
Depends on what you need.
If you specifically only care about moments in time, throwing away the input time zone might be fine.
If the application is more human centric, timezones are often very useful as humans move around but often think about time as timezone-relative. A log of your daily activities would be confusing if a past event logged as 09:16:01 suddenly showed up as 07:16:01 because you're travelling when viewing it.
NAR8789 · 2h 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.
isbvhodnvemrwvn · 1h ago
And then your country ditches/adopts the DST and you have angry customers because your app has messed up their future appointments.
creatonez · 1h ago
For timestamps/instants, sure you can just use UTC. But you cannot do human calendar math on instants, else you will ruin someone's entire day once you inevitably hit relatively common edge cases where civil time matters.
nine_k · 2h 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".
That and the metric system is why en_SE is my preferred locale even though I’m not Swedish or in Sweden
Kwpolska · 1h ago
Which decimal separator does it use? Windows’ "English (Sweden)" locale uses commas.
karambahh · 54m ago
Others point out missing tz.
It's also not that "user friendly": depending on their locale, users will usually expect for instance DD/MM/YYYY. Sorting by YYYY-MM-DD won't feel natural to them.
reacweb · 41m ago
I am french. Everydays, we use DD/MM/YYYY or DD/MM/YY. Sometimes, I encounter YYYY-MM-DD, for example at the beginning of a document reference or in a file name. For me, it feels natural and I have no issue to make this switch mentally. The only problem I encounter is in english: MM/DD/YYYY. Hopefully less and less people are using this insane order.
LukeShu · 3h ago
Except for not including a timezone offset, that's one of the RFC 3339 formats.
magnio · 1h ago
Not exactly computer friendly, since filenames cannot contain ":" on Windows.
integralid · 20m ago
And cannot be longer than 8 characters on DOS.
eadmund · 1h ago
Not all computers are Windows!
And not all computer-users worry even a little bit about compatibility with Windows.
thayne · 5m ago
My main complaint about RFC 3339 is it doesn't have anything for specifying a duration/period or ranges.
mesrik · 52m ago
Anyone else find it odd that C99 strftime() %F and %T equivalents did not make it later revisions ISO 8601 and RFC 3339 ?
%F Equivalent to %Y-%m-%d (the ISO 8601 date format). (C99)
%T The time in 24-hour notation (%H:%M:%S). (SU)
The Op linked page did not recognise these. I tried with the "%FT%T%z" which works fine with date and strftime().
I've probably used %F and %T about 20 years with no issues linux, bsd and mac that I wrote code over the years.
BTW, It would be nice to see some reference or comparison how systems stdlib implementations match with these standards if there is one.
One gripe I've got with RFC3999 and it's not nice to have the semicolon in filename if you intend to use it file or directory name. As it conflicts and easily becoome issue when not quoted while using rsync or any command that thinks colon (:) separates and indicates host name. I'm not sure if colon would cause issues with windows but there is chance it could as it's used indicating device name.
ps. I had to implement many stdlib time.h defined functions my own between -89 - 92 for my then work as Turbo C 2.0 and 3.0/3.1 did not implement these. I recall that last time I touched these and fixed issues was when I got P.J. Plaugers The Standard C Library book when it was brand new -92. When earlier proprietary C-compliers libraries sources had not been available, that Plaugers book was was great help for many :)
mrinterweb · 2h ago
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.
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');
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.
Even your example of alarms is not obvious. If you set a timer, or a daily alarm to wake up by, then yes. But if you set an alarm for some event, like sunrise for example, then you would need a zone.
We may not know the location when we write down a datetime. It could be "wherever I may be at the time".
Even if we do know the location, we cannot know for sure what point in time a future local time refers to because locations can change timezones.
>Even your example of alarms is not obvious. If you set a timer, or a daily alarm to wake up by, then yes. But if you set an alarm for some event, like sunrise for example, then you would need a zone.
That's absolutely right. We need to be able to store points in time and we need to be able to store local times that are relative to locations that are yet to be determined and relative to as yet unknown timezones. The two concepts cannot be merged.
You need a timezone as well.
If I set my alarm clock to 7am, I want it to always wake me at 7am local time regardless of where I happen to be on that day.
If I make an appointment for 7 Sep 2026 at 3pm I'm going to turn up at whatever time counts as 3pm on that date. The government might scrap DST, so the exact point in time is currently unknown.
Many uses of local time cannot be expressed correctly if you are forced to specify a timezone.
The timezone is implicit in the appointment, it's the timezone of the place you're making the appointment at.
Scrapping DST is built into the timezone database IIRC, as are other timezone shifts.
In the SQL example way above, the database is probably assuming UTC, which would make the datetime math give incorrect results (ex: around dst changes) if you interpreted it naively as a local time.
This feels like a very Chesterton's Fence thread.
Yes, but we cannot know which timezone that will be or how it will be defined and therefore we cannot store this appointment as a point in time.
This is what we're talking about, right? Can we store all datetimes as points in time or not? I'm convinced that we cannot always do that because there are datetime semantics that cannot be expressed in that way.
[Edit]
>You wouldn't use a datetime for an alarm clock, just a time
You should tell Apple that. They somehow managed to get this wrong. And I suspect the reason may be that many developers really really want all (date)time specifications to be points in time. They are not.
But if you say I have an appointment at 2026-09-07 15:00:00 in the timezone America/New_York I think that also accounts for future rule changes of that timezone.
I’m no expert on this matter but I believe that’s similar to how the new JS temporal API handles such things
Also, what if I don't know yet where I will be and I want to set a reminder for a particular date and time?
I mean, they sometimes do. You might want to wake up at 7.00 AM in the morning regardless of what timezone you’re in, but if I ask Siri what time sunrise is tomorrow (very relevant for setting my alarm!) she better give it to me in local time taking time zones into account.
Another example: I’ve added all the F1 races and qualifications this year to my calendar (I’m a big fan) so I can easily check that the Italian Grand Prix at Monza starts today at 3.00 PM my local time. If I travel to another timezone, my calendar better adjust, or else I’ll miss the races.
Your definition would have been just storing "hh:mm:ss".
No. If I set a reminder for a particular date and time in the future, I want it to go off at that local date and time wherever I may be.
The location cannot be part of the data type because "local" is sometimes relative to movable objects.
So it's good for local use, but inadequate for any use that's not tied to your local environment. Alarms and etc. are already using it, so it's not about that use case.
There is even more fun corner cases. Say you live at border of timezone. First have a meeting at 12:00 for 45 minutes in one zone, then move westward and now have an other meeting at 12:00. How do you mark these in calendar? Communicate them? Make historical log?
It's potentially a local time, potentially not. It's unspecified and that will cause trouble.
If you want to model "stores open at 8:30am, worldwide" then there are data types for that "time only". They are not "date and time".
When does that happen.
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.
Is there a timezoned version of this that is standardized?
2025-09-07 10:57:00Z+2 would be CEST for example. (+2 hours ahead).
2025-09-07 04:57:00Z-4 would be EDT (4 hours behind UTC)
CEST will always be +2 UTC (unless something really changes politically).
DST just marks that Sweden changes from CEST to CET from October to May. So Swedens offset changes, but the timezone does not change its offset.
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.
If you specifically only care about moments in time, throwing away the input time zone might be fine.
If the application is more human centric, timezones are often very useful as humans move around but often think about time as timezone-relative. A log of your daily activities would be confusing if a past event logged as 09:16:01 suddenly showed up as 07:16:01 because you're travelling when viewing it.
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
It's also not that "user friendly": depending on their locale, users will usually expect for instance DD/MM/YYYY. Sorting by YYYY-MM-DD won't feel natural to them.
And not all computer-users worry even a little bit about compatibility with Windows.
https://en.cppreference.com/w/c/chrono/strftime
Man page strftime shows,
%F Equivalent to %Y-%m-%d (the ISO 8601 date format). (C99) %T The time in 24-hour notation (%H:%M:%S). (SU)
The Op linked page did not recognise these. I tried with the "%FT%T%z" which works fine with date and strftime().
I've probably used %F and %T about 20 years with no issues linux, bsd and mac that I wrote code over the years.
BTW, It would be nice to see some reference or comparison how systems stdlib implementations match with these standards if there is one.
One gripe I've got with RFC3999 and it's not nice to have the semicolon in filename if you intend to use it file or directory name. As it conflicts and easily becoome issue when not quoted while using rsync or any command that thinks colon (:) separates and indicates host name. I'm not sure if colon would cause issues with windows but there is chance it could as it's used indicating device name.
ps. I had to implement many stdlib time.h defined functions my own between -89 - 92 for my then work as Turbo C 2.0 and 3.0/3.1 did not implement these. I recall that last time I touched these and fixed issues was when I got P.J. Plaugers The Standard C Library book when it was brand new -92. When earlier proprietary C-compliers libraries sources had not been available, that Plaugers book was was great help for many :)