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 · 4h 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 · 3h 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 relative to locations that are yet to be determined and relative to as yet unknown timezones. The two concepts cannot be merged.
danlitt · 2h ago
Would you agree then that local time should never be used to represent an instant of time, such as the time of a physical event? If so then the use cases for local time seem very very narrow, in particular the top comment in this thread (adding 1 day and 3 hours to a timestamp) should never use local time, since the result is not well-defined.
akio · 2h ago
No. Local time should nearly always be used to represent the time of future physical events (along side a geographical location, such as an address).
Your method of using a named time zone like “Europe/London” is generally wrong for future physical events, and leads to bugs if and when the actual physical location of the event changes named time zones (which does happen).
If I say meet me in person at 10am March 5th, 2030 in Dnipro, Ukraine, that's specific to a location, not a named time zone.
Why? Because perhaps in 2030 Russia has taken over Dnipro and moved it from Europe/Kyiv to Europe/Moscow.
Our meeting time has obviously not changed, but its exact instant on the universal timeline has changed.
Physical future events are not a fixed instant on the universal timeline, they are a local time + a location.
progval · 2h ago
> Why? Because perhaps in 2030 Russia has taken over Dnipro and moved it from Europe/Kyiv to Europe/Moscow.
Not that in invalidates your overall point, but in that case the TZ database would create a new timezone (eg. named Europe/Dnipro) to reflect that from 1996 to 2030 it was UTC+2/UTC+3 (with EU DST rules); then switched to UTC+3 only.
This reflects that there is a place whose rules changed on 2030. Places don't move to an other existing timezone because that would prevent reasoning about past datetimes.
akio · 2h ago
Good point. As you mention, that doesn’t matter in this case, as even if a new named time zone is added, the stored named time zone would’ve been written before Europe/Dnipro was created (in case anyone’s wondering why this doesn’t invalidate the point).
dvdkon · 2h ago
Yes, local datetimes shouldn't be used to represent instants. But I think you can still add days or hours to them.
Don't think of the hours here as units of time, just as parts of the datetime. It's the same as with months: A month doesn't have a defined length in seconds, but you can still add X months to a date without worry, because you aren't using them as units of time, but as "units of calendar". Duration vs Period in java.time parlance.
fauigerzigerk · 2h ago
We just have to use the correct representation for the use case at hand. All I'm saying is that not all date/times can be stored as an instant in time. An appointment/event reminder is a case in point.
pasc1878 · 5h 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 · 5h 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 · 4h 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.
kelnos · 43m ago
> The timezone is implicit in the appointment, it's the timezone of the place you're making the appointment at.
That's not necessarily the case, though. The location is implicit (or explicit, I guess) in the appointment, but the timezone may have changed by the time the appointment arrives. Say for example, your region decides to stop doing daylight saving time changes. But it's just your region, not the entire existing time zone, so a new zone is created to reflect that.
progval · 30m ago
It depends on how you identify a timezone. If you use an IANA identifier then short of a war it's pretty safe that the place of the appointment will use the same IANA timezone; because those follow changes in DST rules and even changes in offsets.
fauigerzigerk · 4h 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 · 3h 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).
fauigerzigerk · 3h ago
I may misremember as it happened years ago. I thought it was the alarm clock but it's possible that it was an event reminder for an appointment that went off at the incorrect local time.
dotancohen · 1h ago
Those bugs are the leaked implementation detail that the alarm clock does in fact store the time zone internally.
mattclarkdotnet · 3h 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…
fauigerzigerk · 3h ago
Exactly. Maybe it's not clear what my point is. Some people insist on the idea that all date/time specifications can be stored as points in time. This is what I'm disputing.
omnicognate · 2h ago
Please please please read (all of) my sibling comment to the one you're replying to. You're absolutely right about points in time but you're drawing tbe wrong conclusion from it and seem to be unaware that "13:00 on the 12th Sept 2025 according to whatever time conventions are in place in London at that time even if daylight savings is abolished in the UK between now and then" is perfectly expressible using a timezone (Europe/London).
umanwizard · 2h ago
Europe/London is one of the names of a time zone, yes (variously also called Europe/Lisbon, WET, etc.). But what about for cities that don’t have a canonical name in tzdb? You can’t just always do Continent/City; America/Tucson, for example, does not exist.
kelnos · 37m ago
That's not how those named zones work. I live in San Francisco, but my TZ is America/Los_Angeles. You don't need a named zone for every city; you can just pick a large city in the region where time is and always has been the same.
If SF decided to drop DST, but the rest of the state didn't[0], then America/San_Francisco would be created to handle the changes.
This is why you can't accurately record physical appointments by date, time, and timezone. You have to record it as date, time, and physical location, and then the time zone can "float", based on the location and rules in the tzdb, until the appointment happens.
[0] Assuming this were made legal, which is pretty unlikely.
fauigerzigerk · 2h ago
What is my incorrect conclusion?
What I'm saying is that we cannot reliably store a future local time such as "13:00 on the 12th Sept 2025 Europe/London" as an instant in time.
3np · 1h ago
"13:00 on the 12th Sept 2025 Europe/London" is already (a pointer to) an instant in time as much as any unix timestamp. Just a different reference frame. Now it's true you can not know in advance what UTC time will be at that moment which may bring practical concerns if one wants to synchronize that with a contemporary typical computer system clock. It would be true to say that not all points in time can be reliably stored as unix timestamps[0].
Recalling Einstein and that such a thing as global time reference is fundamentally impossible, you're nitpicking while being technically incorrect.
[0]: but please keep defaulting to it in code unless you really know why lol
All I am saying is that it would be incorrect to _store_ a future date/time such as "13:00 on the 12th Sept 2025 Europe/London" as an instant in time, because the instant it refers to is yet to be determined. This is a very simple and pragmatic argument that matters when you choose data types for your database schema.
3np · 55m ago
And I am saying that storing it verbatim as the string "13:00 on the 12th Sept 2025 Europe/London" is an instant in time as much as any other formats and types you can come up with. Just not very parsable by your typical stdlib.
It all boils down to picking the appropriate reference frame, which varies by context. I believe your point should be that there is no single universally applicable reference frame for mapping all future events to future cultural time (and/or that in any case it's not UTC).
fauigerzigerk · 39m ago
>And I am saying that storing it verbatim as the string "13:00 on the 12th Sept 2025 Europe/London" would be an instant in time as much as any other formats and types you can come up with.
No, a future datetime expressed in this string format does not represent a specific instant in time. If you had multiple datetime values from different timezones in this representation, you wouldn't be able to sort them so that earlier ones come before later ones. If they were instants in time, you would be able to do that.
3np · 34m ago
> If you had multiple datetime values from different timezones in this representation, you wouldn't be able to sort them so that earlier ones come before later ones.
That's irrelevant.
Besides, you could, assuming you have a timezone db on the side.
> If they were instants in time, you would be able to do that.
How do you synchronize with and translate to timezones in Andromeda?
fauigerzigerk · 23m ago
>That's irrelevant
It is proof that your format does not represent instants in time because instants in time can be sorted across timezones.
>Besides, you could, assuming you have a timezone db on the side.
No, because you don't have future versions of the timezone database.
omnicognate · 2h ago
No but we can and should store it as a timestamp with a timezone. It is rare for a nominal (date)time to be the correct thing to use. Please do read my other comment.
fauigerzigerk · 1h ago
>No but we can and should store it as a timestamp with a timezone.
It would be highly unusual and misleading to call something a timestamp unless it is a point in time. In Postgres for instance, the timestamp with timezone type represents an instant in time.
This data type cannot be used to store things like reminders for future appointments. It's not rare at all.
akio · 1h ago
That is not quite right. In Postgres, timestamptz (aka timestamp with time zone) represents an instant in time. timestamp (aka timestamp without time zone) represents what you are calling local time. timestamp (without time zone) is exactly what you should use to store future appointments.
Something that often trips people up is that they think timestamptz stores a timestamp plus a time zone (probably because of its unfortunate name). It does not; it always stores a Unix epoch without an extra time zone, converting any zoned timestamp that it is passed.
fauigerzigerk · 52m ago
Yes, you are right.
omnicognate · 3h ago
The vast majority of them really should be points in time. The correct name for a (date)time that isn't is a "nominal" or "naive" date(time), not a local one. Nominal (date)times do indeed have valid use cases, but they are rare.
Taking your example of an appointment, a nominal (date)time would be appropriate if the meeting were to take place at a particular local time but in an as-yet unspecified geographical location, which will be specified later. The form of the appointment would be "we will meet at 13:00 according to the local convention in the place where the meeting actually happens, which is yet to be determined". Here, a nominal time would be appropriate, but note that it would need to be paired with some geographical information prior to the appointment taking place in order to identify a point in time, allowing the meeting to go ahead.
The above is a very unusual situation, though. It's far more likely that the meeting will be either in a location known up front or in no particular location (eg. if it's a video call with participants in multiple countries).
In the first case, the correct thing is to include the geographical timezone of the location where the meeting will take place. For example, if the meeting is in London the timezone would be Europe/London. You raise the concern that the local convention could change, eg. daylight saving time
could be abolished, but that isn't an issue. The "whatever the convention is in operation in London at that time" part is captured in the use of Europe/London as the timezone, and there would be no need to update the (date)time if the convention changes. The (date)time identifies an instant in time as long as the convention doesn't change, but if the convention does change it automatically reflects it.
In the second case we need to define an instant in time so that people know when to attend the meeting. This could be done with a count of milliseconds from an agreed reference instant, but that's not very user friendly. The correct thing to use here is a (date)time with a defined timezone. If there really is no favoured location UTC would be the obvious choice, but any preferred timezone could be used as long as it's indicated in the (date)time so that the specific instant can be resolved. You might want to avoid using a zone like "Europe/London" whose convention could potentially change, although if you did use it the instant at which to to connect would still be well defined at the time of the meeting.
You rightly point out that nominal datetimes don't define instants in time, but that's why you should avoid them. Most use cases should specify a point in time, at least up to local convention in a specific location. Genuine use cases for nominal (date)times are rare. In the vast majority of cases where they are used a timezone really should have been specified. This mistake is extremely common, and it doesn't remotely surprise me if some programmers at Apple have made it.
A brief note on "local" times. These aren't the same thing as nominal times. A local time has an implicit timezone that is the local one according to the current locale. Local (date)times therefore do specify particular instants in time. One of the biggest mistakes people make is to write out local (date)times as nominal (date)times to stores that can be read by code running with different locales. This causes many problems. If you write out a local (date)time include the current time zone!
I ask you please to learn from the above. I know it's hard to prevent comment exchanges turning into arguments, but I'm not trying to win points here. I've taken a chunk of my Sunday morning to explain something I don't find terribly exciting in the hope that the knowledge will benefit anyone who reads it. I really hate being in a situation where I have a timestamp from a log or db or on the wire or something and whoever put it there didn't think to include the information needed to interpret it correctly. It happens to me distressingly often at work. Let's all do better.
Edit: Worth noting that ISO 8601 doesn't allow timezones like Europe/London. That's disappointing but doesn't relieve you of the duty to include the timezone information when persisting (date)times. It just makes it slightly more awkward. Good date/time libraries do support these zones.
akio · 2h ago
You are wrong, and fauigerzigerk is correct.
Future physical events, such as an appointment at a physical location, should be stored as unzoned time plus a location (such as an address), NOT with a named time zone.
This is because physical locations can change named time zones due to political reasons (this has happened many times already).
Storing an appointment time with “Europe/London” only works if your appointment is actually in London and not some other British city (and even that assumes that London never gets divided in the future).
If I say meet me in person at 10am March 5th, 2030 in Dnipro, Ukraine, that's specific to a location, not Europe/Kyiv.
Why? Because perhaps in 2030 Russia has taken over Dnipro and moved it from Europe/Kyiv to Europe/Moscow.
Our meeting time has obviously not changed, but its exact instant on the universal timeline has changed.
This is super important to get right and you are spreading incorrect information that, if followed, will lead to bugs.
omnicognate · 1h ago
If you're going to go to those lengths you will need a way to map the geographical location to a time convention (and you'll probably need something better than an address for the location as those can change too). I don't dispute there are use cases where that may be required, and it's not what I'm advising against.
What I'm explaining is that it's usually wrong to store a nominal (date)time that can't be resolved to an instant in time without assuming extra information that isn't captured.
If fauigerzigerk isn't arguing in favour of doing that, and I've misunderstood the prior discussion, then great. The point should be made anyway, because people doing that is by far the biggest cause of time-related software issues in my extensive experience.
akio · 1h ago
A future appointment at a physical location is usually an agreement between two or more humans. Humans generally don’t use UTC for future physical events, nor they use a time in a named time zone. What they use is a local time and location (often an address).
fauigerzigerk is saying that this, among with others, is the use case for what they are calling “local time,” what you are calling “nominal time,” what Postgres calls “timestamp without time zone,” and what the JS Temporal API calls “ PlainDateTime.”
In my experience engineers not understanding this key point, and believing that zoned time should be used for everything, is its own cause of issues and confusion.
umanwizard · 2h ago
You are technically correct but I’m not convinced it is “super important”. The stakes of not messing up appointment times in the very rare edge case of a territory changing time zones seems pretty low. I’m willing to be convinced that I’m wrong, though.
akio · 1h ago
It is not as rare as you might think.
The most recent time this happened was March of this year, with Chile's Aysén Region dropping DST and moving to the newly created America/Coyhaique.
I used to manage a large application for scheduling shifts at warehouses in many different locations, and storing future events as local timestamps and lazily converting them just before calculations into their location’s zoned time was the only way I could stay sane.
umanwizard · 1h ago
I didn’t mean it’s globally rare, i.e. rare that it happens anywhere. I meant that it’s a rare thing for any given person to experience.
Even for people who live in Aysén, it will probably only happen once in their lives, and the only impact will be a few appointments getting messed up. Is having to fix a few calendar entries once in your life really “super important” to avoid?
akio · 1h ago
The consequences could look something like 50 shift workers showing up an hour late one day, or a user missing a critical meeting.
Dealing with and debugging time zones is already such a confusing mess that I find that anything that makes your application more correct with regards to time zones is worth it. The important thing though is knowing, and then you can make an informed decision on how may shortcuts you want to take with time zones.
If you’re writing software that’s only designed to be used in a small region or by just a few people, then sure, it’s probably not super important.
If you’re writing software that’s used all over the map in places and time zones you can’t predict, well, it helps me sleep better at night.
omnicognate · 1h ago
Why didn't you store them as instants (offset from epoch) or UTC? Using local times, wouldn't your software produce different points in time for the same event when run with a different locale?
akio · 47m ago
The events in question happen at a physical location at a local time, and so are stored as a local time plus longitude and latitude.
If they were stored as instants, and then if a location moved time zones or stopped using DST in the summer, the event’s stored time relative to the expected local time would incorrectly shift.
fauigerzigerk · 2h ago
I'm not sure where our disagreement lies or if there even is a disagreement besides perhaps some terminology. I'm happy to adopt your distinction between local and nominal, but that's not really the point.
My point is very simple. We cannot store all date/time values as a point in time (instant). There are important use cases where the exact point in time cannot (yet) be determined when we store the date/time value.
omnicognate · 2h ago
My point is that those are rare. By far the most common mistake is to store a timestamp that should have a zone without one. If we're agreed on that, and are not trying to use the fact that time conventions can change as an excuse for writing nominal datetimes everywhere then great. I'm really not interested in an argument.
fauigerzigerk · 1h ago
>My point is that those are rare
I disagree. Storing appointment reminders is not rare. Storing the datetime of future social events or deadlines is not rare.
I'm not interested in an argument either. Just use the correct representation for the use case at hand. It doesn't matter how rare or not rare it is in your work.
burntsushi · 1h ago
What's rare is a physical location changing its IANA time zone identifier.
It is absolutely a fact that for the use cases you describe, you do eventually have to turn it into an instant in time. Otherwise you don't know when to issue appointment reminders and so on.
Because a location changing its IANA time zone identifier is rare, then capturing the "nominal" datetime, plus the offset and the time zone identifier is usually sufficient. That information can be encoded using RFC 9557. The offset can be used as a checksum of sorts to avoid silent bugs in cases where the location changes its DST rules. It does not help with your Ukraine example.
However, the only way to make your Ukraine example work is to necessarily have a way of mapping a physical location to an IANA time zone identifier. The IANA tzdb does not provide that on its own. This may be a fair bit of additional work that is not worth doing.
It's definitely wrong to just store an instant in time with a time zone though. You want the local datetime, the offset and the time zone at minimum. I'm surprised nobody in this thread has brought up RFC 9557.
akio · 23m ago
Evan Siroky's Timezone Boundary Builder[0] is a good source of time zone boundary mappings. It can be used via a library in nearly any language you would want[1], or loaded directly into Postgres and used with PostGIS in queries[2] (of course, if you load it into your DB you should have a process for keeping it updated).
It would be wonderful if Jiff supported coordinates-to-tz lookups out of the box :)
I'm aware, yet it doesn't invalidate my point. You'll note that I didn't say it was impossible to do. You would also need to rely on this database being updated similar to the tzdb, which is another data dependency to consider. There is also the problem that there isn't an established interchange format for such things, but there is one for IANA time zone identifiers (RFC 9557).
Finally, the database you linked doesn't appear to track historical data, unlike the tzdb. So if Ukraine reacquired territory, you'd end up with a wrong answer if looking at appointments scheduled in the past.
akio · 2m ago
Past events should just be stored as instants, not as a local time plus location or time zone.
Further, I believe the historical data is meant to be handled by the named time zone, so Russia moving Dnipro to MSK would create a new time zone, then Ukraine reacquiring the territory and moving it back to EET would keep (or further split) the new named time zone, and the historical changes of Dnipro would be handled by tzdb.
So even if you did store past events with a local time plus a location (which you should not do), I don't think Ukraine requiring the territory would cause problems, although we're really stretching my knowledge of IANA named zones and I could certainly be wrong.
omnicognate · 1h ago
Are you arguing in favour of storing a nominal datetime without additional information that allows it to be resolved to an instant in time in those cases, or are you just debating the nature of that extra information?
If the latter, we don't disagree. There's more than one way to do it and plenty of use cases with special requirements (though IANA timezones are sufficient for most purposes). If the former, we profoundly disagree and if you are a professional programmer working in a field that makes significant use of times across multiple regions you will create misery for your colleagues until you change your approach.
But you will at least be far from alone in doing so...
jwr · 3h ago
You seem to assume that "local" is defined and does not change over time. Well I travel a lot, and my "local" could be different next month. Without timezone information I have no idea what a timestamp represents.
fauigerzigerk · 3h ago
>You seem to assume that "local" is defined and does not change over time.
On the contrary, what I'm saying is that we need to be able to store date/time specifications that do not (yet) identify a point in time. Of course we also need to be able to store actual points in time.
"Local" is a pretty vague term. I can refer to a specific place or to an as yet unknown place.
bakje · 5h 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
burntsushi · 1h ago
You also need to record the offset with the datetime and tone zone. Otherwise you won't be able to detect changes to time zone rules.
fauigerzigerk · 4h 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 · 4h 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 · 4h ago
Unless New York gets split into two, Berlin-style, and the parts have different time zones.
mcny · 4h 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 · 3h ago
Yes? Same could be said right now for setting an alarm during the hour skipped/repeated by a DST transition.
OskarS · 4h 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 · 4h 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 · 5h 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 · 5h 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 · 3h 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 · 5h 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 · 4h 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 · 4h ago
good point, never thought of that.
shmerl · 4h 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.
rini17 · 2h ago
But if there's local DST change between today and tomorrow? Then naive calculation of "Add 1 day and 3 hours to a date." is wrong.
Jaxan · 2h ago
So it’s not fit for calculations. But you can still sort it (as a string) and it will be correct. For a digital personal journal it seems fine.
Ekaros · 4h 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?
hdgvhicv · 4h ago
2025-11-02 01:30:00 in New York.
When does that happen.
Symbiote · 2h ago
Twice? I wonder what alarm clock apps decide for this.
GNU date defaults to EDT, but adding the local time zone name can give the other time:
date --utc --date='TZ="America/New_York" 2025-11-02 01:30:00'
Sun 02 Nov 2025 05:30:00 UTC
(Which is 01:30 EDT)
date --utc --date='TZ="America/New_York" 2025-11-02 01:30:00 EST'
Sun 02 Nov 2025 06:30:00
although for London it defaults to GMT:
date --utc --date='TZ="Etc/London" 2025-10-26 01:30:00'
Sun 26 Oct 2025 01:30:00 UTC
date --utc --date='TZ="Etc/London" 2025-10-26 01:30:00 BST'
Sun 26 Oct 2025 00:30:00 BST
It throws an error the other way:
date --utc --date='TZ="Europe/London" 2025-03-30 01:30:00'
date: invalid date ‘TZ="Europe/London" 2025-03-30 01:30:00’
SideburnsOfDoom · 3h 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".
nine_k · 5h 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.
lmm · 1h ago
Specifying an offset, as certain datetime formats do, is worse than not specifying any timezone information at all. I'm not aware of a standardised computer date format that includes the symbolic timezone, sadly.
zarzavat · 49m ago
Agreed, offsets are an anti-pattern. Any time you have a nonzero offset you almost certainly want either a tz name (e.g. Europe/Paris), a local datetime, an instant, or a formatted string.
Datetime + tz name: a point in time and space that is responsive to time zone changes. E.g. Our zoom meeting is on 3 Feb 2026 17:40 in Moscow time.
Local date time: a calendar date that is independent of time zones.
Instant: an exact point in time. e.g. the rocket will launch at 123456789 seconds from the Unix Epoch TAI.
Formatted string: an exact point in time rendered for the human user in their local timezone and calendar, taking into account leap seconds. E.g. The rocket will launch on 7 Ramadan 1447 AH, Saudi time.
rocqua · 5h 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 · 5h 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 · 4h 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 · 4h 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 · 4h 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.
umanwizard · 1h ago
That’s wrong or at least not normally how the term “time zone” is used. We would typically say that Sweden is in one time zone whose offset changes twice a year.
dijit · 48m ago
so CEST is what?
mg · 6h 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 · 5h 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.
creatonez · 4h 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.
NAR8789 · 5h 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 · 4h ago
And then your country ditches/adopts the DST and you have angry customers because your app has messed up their future appointments.
nine_k · 5h 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".
GoblinSlayer · 4h ago
You need time zone to parse time.
zarzavat · 54m ago
Not all datetimes need a timezone. My next birthday is on November 17 2025 at 00:00 (it's not really). It's on that date regardless of where I am in the world, it follows me!
So yes, I agree a local datetime format is necessary but not sufficient.
burntsushi · 20m ago
It's not elegant at all. This is a horrible idea because it doesn't account for time zone transitions. You could even end up with a time that will never appear on your clock.
If you said `2025-03-09 02:30:00`, then that would just be wrong. Because that time never appeared on clocks in New York.
jolmg · 1h ago
> "YYYY-MM-DD hh:mm:ss"
> It is human-friendly and computer-friendly at the same time.
It's not shell-friendly, because of the space. The shell being an interface between humans and the computer, this takes a chunk out of it being human-friendly and computer-friendly. You'll have to worry about quoting the thing, involve messing with IFS when making arrays of the things, extract both pieces out of text columns aligned with spaces, awk's NF wouldn't correspond with number of fields anymore, etc. Would make timestamps unnecessarily annoying to interact with. Better to at least make it an underscore. Still quite readable.
Except for not including a timezone offset, that's one of the RFC 3339 formats.
karambahh · 4h 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 · 4h 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.
jolmg · 55m ago
> Sorting by YYYY-MM-DD won't feel natural to them.
It's dictionary sorting.
magnio · 4h ago
Not exactly computer friendly, since filenames cannot contain ":" on Windows.
integralid · 3h ago
And cannot be longer than 8 characters on DOS.
afiori · 1h ago
Then replace it with _ or anything else it is going to be equally understandable
eadmund · 4h ago
Not all computers are Windows!
And not all computer-users worry even a little bit about compatibility with Windows.
dvh · 2h ago
Mine is YYYY-MM-DD--hh-mm-ss
rdsubhas · 2h ago
In most countries in the world, 24 hour time is just not human (user) friendly.
Programmer-friendly for debugging? Sorry No. I don't mind the extra T in between and I'd actually like to see the timezone or zulu in logs when debugging.
A counter view would be: it's half-human-half-computer inclined, but not objectively good for either.
I fail to see why it is not considered human friendly. Its more specific, a day is 24 hours, at least I much prefer it to "am/pm".
afiori · 1h ago
Especially since there is very little logic to which 12 is midday and which is midnight does not have a clear logic
afiori · 1h ago
The extra T impacts legibility quite a lot and most systems that follow the standard either normalize everything to UTC or use a single global timezone to format everything
bpavuk · 14m ago
fun fact - ATProto requires you to store all the datetime strings in a format that's compliant with both RFC 3339 and ISO 8601 plus you cannot specify time without date.
when I worked on datetime portion of Katproto, I had this link pinned for quite some time as a reference! ah, nostalgia...
also, post factum, I find this technical decision actually good - instead of supporting all possible variations of ISO 8601 or all the variations of RFC 3339, why not just support the intersection? that way, the format will be parseable by anything compliant with any standard of these two, and you only need to handle a very small set of branches.
drob518 · 25m ago
Every programmer starts off thinking that dates and times are easy. “Just do …,” they’ll say. And then you realize that ISO 8601 has more than a few ways just to write down the time, let alone manipulate it. Dates and times are a very, very deep rabbit hole. Fortunately most of the time you can get by with just local dates and times or zoned dates and times.
mrinterweb · 5h 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.
mesrik · 4h 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 :)
thayne · 3h ago
My main complaint about RFC 3339 is it doesn't have anything for specifying a duration/period or ranges.
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 relative to locations that are yet to be determined and relative to as yet unknown timezones. The two concepts cannot be merged.
Your method of using a named time zone like “Europe/London” is generally wrong for future physical events, and leads to bugs if and when the actual physical location of the event changes named time zones (which does happen).
If I say meet me in person at 10am March 5th, 2030 in Dnipro, Ukraine, that's specific to a location, not a named time zone.
Why? Because perhaps in 2030 Russia has taken over Dnipro and moved it from Europe/Kyiv to Europe/Moscow.
Our meeting time has obviously not changed, but its exact instant on the universal timeline has changed.
Physical future events are not a fixed instant on the universal timeline, they are a local time + a location.
Not that in invalidates your overall point, but in that case the TZ database would create a new timezone (eg. named Europe/Dnipro) to reflect that from 1996 to 2030 it was UTC+2/UTC+3 (with EU DST rules); then switched to UTC+3 only.
This reflects that there is a place whose rules changed on 2030. Places don't move to an other existing timezone because that would prevent reasoning about past datetimes.
Don't think of the hours here as units of time, just as parts of the datetime. It's the same as with months: A month doesn't have a defined length in seconds, but you can still add X months to a date without worry, because you aren't using them as units of time, but as "units of calendar". Duration vs Period in java.time parlance.
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.
That's not necessarily the case, though. The location is implicit (or explicit, I guess) in the appointment, but the timezone may have changed by the time the appointment arrives. Say for example, your region decides to stop doing daylight saving time changes. But it's just your region, not the entire existing time zone, so a new zone is created to reflect that.
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.
If SF decided to drop DST, but the rest of the state didn't[0], then America/San_Francisco would be created to handle the changes.
This is why you can't accurately record physical appointments by date, time, and timezone. You have to record it as date, time, and physical location, and then the time zone can "float", based on the location and rules in the tzdb, until the appointment happens.
[0] Assuming this were made legal, which is pretty unlikely.
What I'm saying is that we cannot reliably store a future local time such as "13:00 on the 12th Sept 2025 Europe/London" as an instant in time.
Recalling Einstein and that such a thing as global time reference is fundamentally impossible, you're nitpicking while being technically incorrect.
[0]: but please keep defaulting to it in code unless you really know why lol
https://doi.org/10.5281/zenodo.17070518
It all boils down to picking the appropriate reference frame, which varies by context. I believe your point should be that there is no single universally applicable reference frame for mapping all future events to future cultural time (and/or that in any case it's not UTC).
No, a future datetime expressed in this string format does not represent a specific instant in time. If you had multiple datetime values from different timezones in this representation, you wouldn't be able to sort them so that earlier ones come before later ones. If they were instants in time, you would be able to do that.
That's irrelevant.
Besides, you could, assuming you have a timezone db on the side.
> If they were instants in time, you would be able to do that.
How do you synchronize with and translate to timezones in Andromeda?
It is proof that your format does not represent instants in time because instants in time can be sorted across timezones.
>Besides, you could, assuming you have a timezone db on the side.
No, because you don't have future versions of the timezone database.
It would be highly unusual and misleading to call something a timestamp unless it is a point in time. In Postgres for instance, the timestamp with timezone type represents an instant in time.
This data type cannot be used to store things like reminders for future appointments. It's not rare at all.
Something that often trips people up is that they think timestamptz stores a timestamp plus a time zone (probably because of its unfortunate name). It does not; it always stores a Unix epoch without an extra time zone, converting any zoned timestamp that it is passed.
Taking your example of an appointment, a nominal (date)time would be appropriate if the meeting were to take place at a particular local time but in an as-yet unspecified geographical location, which will be specified later. The form of the appointment would be "we will meet at 13:00 according to the local convention in the place where the meeting actually happens, which is yet to be determined". Here, a nominal time would be appropriate, but note that it would need to be paired with some geographical information prior to the appointment taking place in order to identify a point in time, allowing the meeting to go ahead.
The above is a very unusual situation, though. It's far more likely that the meeting will be either in a location known up front or in no particular location (eg. if it's a video call with participants in multiple countries).
In the first case, the correct thing is to include the geographical timezone of the location where the meeting will take place. For example, if the meeting is in London the timezone would be Europe/London. You raise the concern that the local convention could change, eg. daylight saving time could be abolished, but that isn't an issue. The "whatever the convention is in operation in London at that time" part is captured in the use of Europe/London as the timezone, and there would be no need to update the (date)time if the convention changes. The (date)time identifies an instant in time as long as the convention doesn't change, but if the convention does change it automatically reflects it.
In the second case we need to define an instant in time so that people know when to attend the meeting. This could be done with a count of milliseconds from an agreed reference instant, but that's not very user friendly. The correct thing to use here is a (date)time with a defined timezone. If there really is no favoured location UTC would be the obvious choice, but any preferred timezone could be used as long as it's indicated in the (date)time so that the specific instant can be resolved. You might want to avoid using a zone like "Europe/London" whose convention could potentially change, although if you did use it the instant at which to to connect would still be well defined at the time of the meeting.
You rightly point out that nominal datetimes don't define instants in time, but that's why you should avoid them. Most use cases should specify a point in time, at least up to local convention in a specific location. Genuine use cases for nominal (date)times are rare. In the vast majority of cases where they are used a timezone really should have been specified. This mistake is extremely common, and it doesn't remotely surprise me if some programmers at Apple have made it.
A brief note on "local" times. These aren't the same thing as nominal times. A local time has an implicit timezone that is the local one according to the current locale. Local (date)times therefore do specify particular instants in time. One of the biggest mistakes people make is to write out local (date)times as nominal (date)times to stores that can be read by code running with different locales. This causes many problems. If you write out a local (date)time include the current time zone!
I ask you please to learn from the above. I know it's hard to prevent comment exchanges turning into arguments, but I'm not trying to win points here. I've taken a chunk of my Sunday morning to explain something I don't find terribly exciting in the hope that the knowledge will benefit anyone who reads it. I really hate being in a situation where I have a timestamp from a log or db or on the wire or something and whoever put it there didn't think to include the information needed to interpret it correctly. It happens to me distressingly often at work. Let's all do better.
Edit: Worth noting that ISO 8601 doesn't allow timezones like Europe/London. That's disappointing but doesn't relieve you of the duty to include the timezone information when persisting (date)times. It just makes it slightly more awkward. Good date/time libraries do support these zones.
Future physical events, such as an appointment at a physical location, should be stored as unzoned time plus a location (such as an address), NOT with a named time zone.
This is because physical locations can change named time zones due to political reasons (this has happened many times already).
Storing an appointment time with “Europe/London” only works if your appointment is actually in London and not some other British city (and even that assumes that London never gets divided in the future).
If I say meet me in person at 10am March 5th, 2030 in Dnipro, Ukraine, that's specific to a location, not Europe/Kyiv.
Why? Because perhaps in 2030 Russia has taken over Dnipro and moved it from Europe/Kyiv to Europe/Moscow.
Our meeting time has obviously not changed, but its exact instant on the universal timeline has changed.
This is super important to get right and you are spreading incorrect information that, if followed, will lead to bugs.
What I'm explaining is that it's usually wrong to store a nominal (date)time that can't be resolved to an instant in time without assuming extra information that isn't captured.
If fauigerzigerk isn't arguing in favour of doing that, and I've misunderstood the prior discussion, then great. The point should be made anyway, because people doing that is by far the biggest cause of time-related software issues in my extensive experience.
fauigerzigerk is saying that this, among with others, is the use case for what they are calling “local time,” what you are calling “nominal time,” what Postgres calls “timestamp without time zone,” and what the JS Temporal API calls “ PlainDateTime.”
In my experience engineers not understanding this key point, and believing that zoned time should be used for everything, is its own cause of issues and confusion.
The most recent time this happened was March of this year, with Chile's Aysén Region dropping DST and moving to the newly created America/Coyhaique.
https://data.iana.org/time-zones/tzdb/NEWS
I used to manage a large application for scheduling shifts at warehouses in many different locations, and storing future events as local timestamps and lazily converting them just before calculations into their location’s zoned time was the only way I could stay sane.
Even for people who live in Aysén, it will probably only happen once in their lives, and the only impact will be a few appointments getting messed up. Is having to fix a few calendar entries once in your life really “super important” to avoid?
Dealing with and debugging time zones is already such a confusing mess that I find that anything that makes your application more correct with regards to time zones is worth it. The important thing though is knowing, and then you can make an informed decision on how may shortcuts you want to take with time zones.
If you’re writing software that’s only designed to be used in a small region or by just a few people, then sure, it’s probably not super important.
If you’re writing software that’s used all over the map in places and time zones you can’t predict, well, it helps me sleep better at night.
If they were stored as instants, and then if a location moved time zones or stopped using DST in the summer, the event’s stored time relative to the expected local time would incorrectly shift.
My point is very simple. We cannot store all date/time values as a point in time (instant). There are important use cases where the exact point in time cannot (yet) be determined when we store the date/time value.
I disagree. Storing appointment reminders is not rare. Storing the datetime of future social events or deadlines is not rare.
I'm not interested in an argument either. Just use the correct representation for the use case at hand. It doesn't matter how rare or not rare it is in your work.
It is absolutely a fact that for the use cases you describe, you do eventually have to turn it into an instant in time. Otherwise you don't know when to issue appointment reminders and so on.
Because a location changing its IANA time zone identifier is rare, then capturing the "nominal" datetime, plus the offset and the time zone identifier is usually sufficient. That information can be encoded using RFC 9557. The offset can be used as a checksum of sorts to avoid silent bugs in cases where the location changes its DST rules. It does not help with your Ukraine example.
However, the only way to make your Ukraine example work is to necessarily have a way of mapping a physical location to an IANA time zone identifier. The IANA tzdb does not provide that on its own. This may be a fair bit of additional work that is not worth doing.
It's definitely wrong to just store an instant in time with a time zone though. You want the local datetime, the offset and the time zone at minimum. I'm surprised nobody in this thread has brought up RFC 9557.
It would be wonderful if Jiff supported coordinates-to-tz lookups out of the box :)
[0]: https://github.com/evansiroky/timezone-boundary-builder/rele...
[1]: https://github.com/evansiroky/timezone-boundary-builder#look...
[2]: https://www.crunchydata.com/blog/timezone-transformation-usi...
Finally, the database you linked doesn't appear to track historical data, unlike the tzdb. So if Ukraine reacquired territory, you'd end up with a wrong answer if looking at appointments scheduled in the past.
Further, I believe the historical data is meant to be handled by the named time zone, so Russia moving Dnipro to MSK would create a new time zone, then Ukraine reacquiring the territory and moving it back to EET would keep (or further split) the new named time zone, and the historical changes of Dnipro would be handled by tzdb.
So even if you did store past events with a local time plus a location (which you should not do), I don't think Ukraine requiring the territory would cause problems, although we're really stretching my knowledge of IANA named zones and I could certainly be wrong.
If the latter, we don't disagree. There's more than one way to do it and plenty of use cases with special requirements (though IANA timezones are sufficient for most purposes). If the former, we profoundly disagree and if you are a professional programmer working in a field that makes significant use of times across multiple regions you will create misery for your colleagues until you change your approach.
But you will at least be far from alone in doing so...
On the contrary, what I'm saying is that we need to be able to store date/time specifications that do not (yet) identify a point in time. Of course we also need to be able to store actual points in time.
"Local" is a pretty vague term. I can refer to a specific place or to an as yet unknown place.
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?
When does that happen.
GNU date defaults to EDT, but adding the local time zone name can give the other time:
although for London it defaults to GMT: It throws an error the other way: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".
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.
Datetime + tz name: a point in time and space that is responsive to time zone changes. E.g. Our zoom meeting is on 3 Feb 2026 17:40 in Moscow time.
Local date time: a calendar date that is independent of time zones.
Instant: an exact point in time. e.g. the rocket will launch at 123456789 seconds from the Unix Epoch TAI.
Formatted string: an exact point in time rendered for the human user in their local timezone and calendar, taking into account leap seconds. E.g. The rocket will launch on 7 Ramadan 1447 AH, Saudi time.
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.
So yes, I agree a local datetime format is necessary but not sufficient.
For example, what is the answer to in New York?
If you said `2025-03-09 02:30:00`, then that would just be wrong. Because that time never appeared on clocks in New York.> It is human-friendly and computer-friendly at the same time.
It's not shell-friendly, because of the space. The shell being an interface between humans and the computer, this takes a chunk out of it being human-friendly and computer-friendly. You'll have to worry about quoting the thing, involve messing with IFS when making arrays of the things, extract both pieces out of text columns aligned with spaces, awk's NF wouldn't correspond with number of fields anymore, etc. Would make timestamps unnecessarily annoying to interact with. Better to at least make it an underscore. Still quite readable.
[0] https://stackoverflow.com/a/58633651
I'd like an en_EU definition to be added, except I went to find an official definition[1], and found the EU uses both.
Elsewhere [2] it says the use of a comma is due to "technical limitations".
I use en_GB or en_IE, but
so I get ISO dates in many GNU programs like "ls".[1] https://style-guide.europa.eu/en/content/-/isg/topic?identif...
[2] https://commission.europa.eu/system/files/2023-11/styleguide... §6.10.
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.
It's dictionary sorting.
And not all computer-users worry even a little bit about compatibility with Windows.
Programmer-friendly for debugging? Sorry No. I don't mind the extra T in between and I'd actually like to see the timezone or zulu in logs when debugging.
A counter view would be: it's half-human-half-computer inclined, but not objectively good for either.
I fail to see why it is not considered human friendly. Its more specific, a day is 24 hours, at least I much prefer it to "am/pm".
when I worked on datetime portion of Katproto, I had this link pinned for quite some time as a reference! ah, nostalgia...
also, post factum, I find this technical decision actually good - instead of supporting all possible variations of ISO 8601 or all the variations of RFC 3339, why not just support the intersection? that way, the format will be parseable by anything compliant with any standard of these two, and you only need to handle a very small set of branches.
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 :)