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:
Me: SQLite: Add 1 day and 3 hours to a date.
Perplexity: SELECT DATETIME('2025-09-07 07:51:00', '+1 day', '+3 hours');
It is not computer-friendly because the timezone is unspecified. And in some timezones, it is ambiguous during changes from DST to winter time.
Slap a Zulu on there for a little more safety and consistency. https://www.noaa.gov/jetstream/time
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.
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.
>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.
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.
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.
> 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.
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).
How do the time databases handle location renaming (eg in 2030, Dnipro becomes Putinville?
Each record encodes optional FROM and TO fields: https://en.wikipedia.org/wiki/Tz_database
> Why? Because perhaps in 2030 Russia has taken over Dnipro and moved it from Europe/Kyiv to Europe/Moscow.
I think in this case Europe/Kyiv would actually change its UTC offset to match Europe/Moscow, which I'm pretty sure the TZ database would handle just fine.
> Our meeting time has obviously not changed, but its exact instant on the universal timeline has changed.
I think a sentence like this should jump out in big red letters. At face value it is not meaningful - how can our meeting time have not changed if the exact instant it occurs has changed?
If you chase this thought to its logical conclusion then it is not as obvious as you suggest. For instance, the number of hours between now and your proposed meeting has changed. Two meetings that happened to be simultaneous before now are no longer simultaneous because their relative UTC offsets changed. Is that a bug? What if your future physical event is the arrival of a train?
The choice in front of you is to pick a completely precise specification on which everyone agrees (the "instant of time") with an incomplete specification which you admit yourself may change in the future. My vote is to at least encode something unambiguous, and then to adjust it if my vague notion (local time) changes.
> I think in this case Europe/Kyiv would actually change its UTC offset to match Europe/Moscow, which I'm pretty sure the TZ database would handle just fine.
Another user has already responded to the rest of your comment, so I’ll just respond to this.
In the Ukraine scenario Russia does not control Kyiv, so no, Europe/Kyiv would not change its offset.
> how can our meeting time have not changed if the exact instant it occurs has changed?
Because human time is not a numeric offset, but a name of relevant points.
> The choice in front of you is to pick a completely precise specification on which everyone agrees (the "instant of time") with an incomplete specification which you admit yourself may change in the future. My vote is to at least encode something unambiguous
The incomplete ambiguous specification is the one everyone agrees to, programmers just don't like them.
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.
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.
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.
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.
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.
>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.
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).
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.
Calendar has an option to enable/disable time zone support, but that’s not a very well-known option…
Those bugs are the leaked implementation detail that the alarm clock does in fact store the time zone internally.
It is possible, but I’m honestly not convinced.
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…
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.
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).
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.
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.
I think you’re agreeing with me. My point was that the tzdb named zones do not provide a generally accepted way to denote “the time in Tucson” or “the time in San Francisco” that would be robust to those splitting from Phoenix or LA, respectively. You need to use some system other than tzdb named zones for that purpose (e.g. lat/long, like you mentioned).
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.
"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.
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).
>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.
> 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?
>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.
I'm jumping in here to hopefully clarify:
"13:00 December 25 2025 Europe/London" is local time but its Unix timestamp is an estimate depending on how the tzdata database looks right now.
"13:00 December 25 2025 +0100" is also local time but it is immutable.
Using the latter can only be done reliably for present and past (but it conveniently avoids looking up the offset later). All future times must use the former to be stable otherwise you should probably be using UTC.
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.
>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.
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.
Yes, you are right.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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?
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.
That's logically fine, although it strikes me as likely overkill since your system has to be able to look up a convention by lat/long in order to get an instant in time, which is not trivial to do and for most use cases would be a more frequent source of errors than changing timezone definitions. I don't know the details of your use case though, and this could well be the appropriate representation. The main thing is that enough information is present to identify an instant in time. Your scheme isn't the nominal-datetime-only representation that I pointed out is frequently used but rarely correct.
We agree that you generally want some information that lets you resolve your event to an IANA time zone for calculations :)
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.
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.
>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.
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.
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 :)
[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...
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.
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, call it Europe/Dnipro, then Ukraine reacquiring the territory and moving it back to EET would keep (or further split) Europe/Dnipro, 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 reacquiring the territory would cause problems, although we're really stretching my knowledge of IANA named zones and I could certainly be wrong.
> Past events should just be stored as instants, not as a local time plus location or time zone.
Appointments become past events. Sounds like an operational nightmare to convert all of them right as they become past events.
And you absolutely want the time zone (and offset) if you want to show past event as a local time for where that event was held. You don't need the location because you know what time zone rules governed that location at that point in time in the past. It won't change.
Please consider that I phrased my comment in engineering terms. I already acknowledged that you want a physical location for the best results in all cases, as you have pointed out in this thread. But I also was careful to contextualize it in engineering terms: storing that information comes with extra engineering costs over just storing an RFC 9557 string. Sometimes those costs are worth it, but certainly not for every use case.
> 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, call it Europe/Dnipro, then Ukraine reacquiring the territory and moving it back to EET would keep (or further split) Europe/Dnipro, and the historical changes of Dnipro would be handled by tzdb.
I can believe that this is what would happen.
> Appointments become past events. Sounds like an operational nightmare to convert all of them right as they become past events.
That is fair. In some models there's a natural separation between a scheduled-at time and a happened-at time (e.g., in one I worked on scheduled_events was a separate table from past_events), but I accept that's certainly not all, or even most. I shouldn't have made such a blanket statement. I do believe the statement is good advice in cases where your data does not mix both future and past times.
> Sometimes those costs are worth it, but certainly not for every use case.
This is also fair. My experience with time zones has been the more correct I can make my time models, the better I sleep at night, but of course you're right engineering involves tradeoffs. I think it's important to at least know the most correct way so that you are making educated decisions in your tradeoffs.
Also, FWIW I'm not the person you originally replied to, although the Ukraine example was mine.
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...
> 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.
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.
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
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?
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.
Unless New York gets split into two, Berlin-style, and the parts have different time zones.
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?
Yes? Same could be said right now for setting an alarm during the hour skipped/repeated by a DST transition.
You also need to record the offset with the datetime and time zone. Otherwise you won't be able to detect changes to time zone rules.
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.
>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.
> 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.
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.
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.
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".
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.
>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.
I don’t understand your objection. Local date and time is always bound to a local timezone, it‘s just implicit. Even in case of movable objects, the exact moment of time is defined by the watch aboard that object. You are on a ship and you wake up at 7am to get ready for breakfast? The exact moment of time when it happens is in the local time zone. The bar around the corner opens at 4pm? It’s in the local timezone, no matter how it changes. And „local“ means the timezone is defined by location, a ship, a city etc, so to calculate the exact moment of time you do location timezone lookup. Your phone does that automatically, picking up the timezone from cell tower and adjusting your local clock, so that alarm set at 7 (which is LocalTime) would work correctly.
> Local date and time is always bound to a local timezone, it‘s just implicit.
It does not that's the key of this argument. Here local means "on this device", whatever dumb time this has.
Do you understand what „implicit“ means?
good point, never thought of that.
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.
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.
I think 'local' in this context could also simply mean 'wall', as in wall clock time. When my friend asks me the date and time, I don't have to bother with time zones.
This type of date/time is also very useful to store in a computer.
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?
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.
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.
If you put times in a database without timezone you will regret it
2025-11-02 01:30:00 in New York.
When does that happen.
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
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
date --utc --date='TZ="Europe/London" 2025-03-30 01:30:00'
date: invalid date ‘TZ="Europe/London" 2025-03-30 01:30:00’> 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".
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.
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?
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)
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)
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.
At that point, just give me
2025-09-07T11:30:31.304[Europe/Riga]
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.
so CEST is what?
An offset from UTC.
Wikipedia calls it "the standard clock time observed during the period of summer daylight-saving in those European countries which observe Central European Time (CET; UTC+01:00) during the other part of the year."
Note the word "zone" does not appear in the above.
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.
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.
> Datetime + tz name: a point in time and space that is responsive to time zone changes
No. It isn't a point in time, because time zone transition rules can and do change. You need an offset as well. Then you can choose which thing you want to prioritize[1] when converting it to an instant in time.
This is what RFC 9557 is for.
[1]: https://docs.rs/jiff/latest/jiff/tz/enum.OffsetConflict.html
What use case is there for preferring the offset (that wouldn't be better served by using instants)?
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.
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.
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.
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.
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".
And then your country ditches/adopts the DST and you have angry customers because your app has messed up their future appointments.
You need time zone to parse time.
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.
It's also the Swedish time format I believe[0]
That and the metric system is why en_SE is my preferred locale even though I’m not Swedish or in Sweden
Which decimal separator does it use? Windows’ "English (Sweden)" locale uses commas.
I'd assume comma, like en_DK.
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
export TIME_STYLE=long-iso
[1] https://style-guide.europa.eu/en/content/-/isg/topic?identif...
[2] https://commission.europa.eu/system/files/2023-11/styleguide... §6.10.
Except for not including a timezone offset, that's one of the RFC 3339 formats.
> "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.
Not exactly computer friendly, since filenames cannot contain ":" on Windows.
And cannot be longer than 8 characters on DOS.
Then replace it with _ or anything else it is going to be equally understandable
Not all computers are Windows!
And not all computer-users worry even a little bit about compatibility with Windows.
Considering that most normie non-tech people use Windows, compatibility with Windows is important.
> It is so elegant and common that even though it is not part of a standard ...
YYYY-MM-DD hh:mm:ss seems valid ISO 8601 to me, isn't it? Neither the "T" nor the timezone are required as far as I recall.
EDIT: The site says ISO 8601-1:2019 requires a T for datetimes, and that even though previous editions allowed for no T, a space was never allowed. This is shocking news to me.
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.
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.
> Sorting by YYYY-MM-DD won't feel natural to them.
It's dictionary sorting.
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.
For example, what is the answer to in New York?
SELECT DATETIME('2025-03-07 23:30:00', '+1 day', '+3 hours');
Mine is YYYY-MM-DD--hh-mm-ss
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.
"most countries in the world" are perfectly fine with the 24 hour clock: https://en.wikipedia.org/wiki/Date_and_time_representation_b...
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".
Especially since there is very little logic to which 12 is midday and which is midnight does not have a clear logic
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
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.
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.
Anyone else find it odd that C99 strftime() %F and %T equivalents did not make it later revisions ISO 8601 and RFC 3339 ?
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 :)
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.
My main complaint about RFC 3339 is it doesn't have anything for specifying a duration/period or ranges.
Everything that isn't MDY is ok. MDY - burn in hell.
You need to scroll that table: 8601 has so so many formats that are just as worthless without context as MDY. %C or %h%m are egregious.
What makes MDY special is that it is worthless even with its normal context yet still widely used.
Those you mention make perfect sense in context: %C is usefull for historians (would you rather be parsing roman numbers?) and %h%m is good for voice radio transmission. Ideally you want to tag a format so that you have context, but I guess that's a bit difficult to do without introducing localization. It's somewhat akin to the issues with less common script in Unicode - yes, those are somewhat weird, but they do have a purpose. The standard tries to encompass every usecase rather than take a YAGNI approach, which is a sensible (if opinionated) thing to do.
On the contrary, MDY would appear in the same context you would expect DMY or YMD. It's only supposed advantage is that it maps English word order. But it is unsortable without parsing.
From last month; https://news.ycombinator.com/item?id=28976526
[dead]
The difference is that `date`, the command, and `chrono` the Rust crate implement RFC 3339, so we don't need to worry about ISO :)