| |
| ▲ | fauigerzigerk 3 days ago | parent | next [-] | | >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 3 days ago | parent | next [-] | | 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 3 days ago | parent | next [-] | | 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. | | |
| ▲ | frizlab 2 days ago | parent [-] | | Calendar has an option to enable/disable time zone support, but that’s not a very well-known option… |
| |
| ▲ | dotancohen 3 days ago | parent | prev [-] | | Those bugs are the leaked implementation detail that the alarm clock does in fact store the time zone internally. | | |
| |
| ▲ | mattclarkdotnet 3 days ago | parent | prev | next [-] | | 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 3 days ago | parent [-] | | 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 3 days ago | parent [-] | | 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 3 days ago | parent | next [-] | | 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 3 days ago | parent [-] | | 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. | | |
| ▲ | umanwizard 3 days ago | parent [-] | | 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). |
|
| |
| ▲ | fauigerzigerk 3 days ago | parent | prev [-] | | 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 3 days ago | parent | next [-] | | "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 https://doi.org/10.5281/zenodo.17070518 | | |
| ▲ | fauigerzigerk 3 days ago | parent [-] | | 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 3 days ago | parent [-] | | 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 3 days ago | parent [-] | | >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. | | |
| ▲ | hebocon 2 days ago | parent | next [-] | | 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. | |
| ▲ | 3np 3 days ago | parent | prev [-] | | > 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 3 days ago | parent [-] | | >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 3 days ago | parent | prev [-] | | 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 3 days ago | parent [-] | | >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 3 days ago | parent [-] | | 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. | | |
|
|
|
|
|
| |
| ▲ | omnicognate 3 days ago | parent | prev [-] | | 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... |
|
|
|
|
| |
| ▲ | kelnos 3 days ago | parent | prev [-] | | > 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. | | |
| ▲ | 3 days ago | parent | next [-] | | [deleted] | |
| ▲ | progval 3 days ago | parent | prev [-] | | 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. |
|
|
