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 3 days ago | parent | next [-]

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 3 days ago | parent | next [-]

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 3 days ago \| parent [-]
		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 3 days ago | parent | prev [-]

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 3 days ago | parent [-]

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.

▲

umanwizard 3 days ago | parent | next [-]

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 3 days ago \| parent [-]
		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 3 days ago | parent | prev [-]

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 3 days ago | parent [-]

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.

▲

omnicognate 3 days ago | parent [-]

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.

	▲	akio 3 days ago \| parent [-]
		We agree that you generally want some information that lets you resolve your event to an IANA time zone for calculations :)

▲

fauigerzigerk 3 days ago | parent | prev [-]

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 3 days ago | parent [-]

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 3 days ago | parent [-]

>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 3 days ago | parent | next [-]

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 3 days ago | parent [-]

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...

▲

burntsushi 3 days ago | parent [-]

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 3 days ago | parent [-]

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.

▲

burntsushi 3 days ago | parent [-]

> 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.

	▲	akio 2 days ago \| parent [-]
		> 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.

▲

omnicognate 3 days ago | parent | prev [-]

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...