5 ms·

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 an

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.

bakje 1y ago
This is true when using a UTC offset as it has any potential DST already applied, so it can’t adapt to changes like that. But if you say I have an appointment at 2026-09-07 15:00:00 in the timezone America/New_York I think that also accounts for future rule changes of that timezone. I’m no expert on this matter but I believe that’s similar to how the new JS temporal API handles such things
- bloak 1y ago
  Unless New York gets split into two, Berlin-style, and the parts have different time zones.
  - mcny 1y ago
    Should it ring twice if you go across the border one way? Should it not ring if you go across the border the other way?
    - oasisaimlessly 1y ago
      Yes? Same could be said right now for setting an alarm during the hour skipped/repeated by a DST transition.
- fauigerzigerk 1y ago
  If the definition of timezone names can change, then the combination of a future datetime and a timezone name does not identify a point in time. Also, what if I don't know yet where I will be and I want to set a reminder for a particular date and time?
- cwillu 1y ago
  If I set my cellphone alarm to go off at 6am, and it goes off at 8am instead “because it's currently 6am in new york”, the alarm clock fucked up.
- burntsushi 1y ago
  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.
OskarS 1y ago
> No, I think it's very important to understand that local times in the future do not identify a point in time and that local times are not necessarily tied to any particular location. I mean, they sometimes do. You might want to wake up at 7.00 AM in the morning regardless of what timezone you’re in, but if I ask Siri what time sunrise is tomorrow (very relevant for setting my alarm!) she better give it to me in local time taking time zones into account. Another example: I’ve added all the F1 races and qualifications this year to my calendar (I’m a big fan) so I can easily check that the Italian Grand Prix at Monza starts today at 3.00 PM my local time. If I travel to another timezone, my calendar better adjust, or else I’ll miss the races.
- fauigerzigerk 1y ago
  That's my whole point really. We need both points in time and (date)times that are relative to some possibly unknown location. These concepts cannot be merged.
rendaw 1y ago
You wouldn't use a datetime for an alarm clock, just a time. The timezone is implicit in the appointment, it's the timezone of the place you're making the appointment at. Scrapping DST is built into the timezone database IIRC, as are other timezone shifts. In the SQL example way above, the database is probably assuming UTC, which would make the datetime math give incorrect results (ex: around dst changes) if you interpreted it naively as a local time. This feels like a very Chesterton's Fence thread.
- fauigerzigerk 1y ago
  >The timezone is implicit in the appointment, it's the timezone of the place you're making the appointment at. Yes, but we cannot know which timezone that will be or how it will be defined and therefore we cannot store this appointment as a point in time. This is what we're talking about, right? Can we store all datetimes as points in time or not? I'm convinced that we cannot always do that because there are datetime semantics that cannot be expressed in that way. [Edit] >You wouldn't use a datetime for an alarm clock, just a time You should tell Apple that. They somehow managed to get this wrong. And I suspect the reason may be that many developers really really want all (date)time specifications to be points in time. They are not.
  - mattclarkdotnet 1y ago
    Of course you want to be able to say 03:00 Europe/London for calendar appointments. Which it is true is not a timezone, and needs to be stored separately from the date time identifier…
    - fauigerzigerk 1y ago
      Exactly. Maybe it's not clear what my point is. Some people insist on the idea that all date/time specifications can be stored as points in time. This is what I'm disputing.
      - omnicognate 1y ago
jwr 1y ago
You seem to assume that "local" is defined and does not change over time. Well I travel a lot, and my "local" could be different next month. Without timezone information I have no idea what a timestamp represents.
- fauigerzigerk 1y ago
  >You seem to assume that "local" is defined and does not change over time. On the contrary, what I'm saying is that we need to be able to store date/time specifications that do not (yet) identify a point in time. Of course we also need to be able to store actual points in time. "Local" is a pretty vague term. I can refer to a specific place or to an as yet unknown place.

bakje 1y ago

This is true when using a UTC offset as it has any potential DST already applied, so it can’t adapt to changes like that. But if you say I have an appointment at 2026-09-07 15:00:00 in the timezone America/New_York I think that also accounts for future rule changes of that timezone. I’m no expert on this matter but I believe that’s similar to how the new JS temporal API handles such things

bloak 1y ago
Unless New York gets split into two, Berlin-style, and the parts have different time zones.
- mcny 1y ago
  Should it ring twice if you go across the border one way? Should it not ring if you go across the border the other way?
  - oasisaimlessly 1y ago
    Yes? Same could be said right now for setting an alarm during the hour skipped/repeated by a DST transition.
fauigerzigerk 1y ago
If the definition of timezone names can change, then the combination of a future datetime and a timezone name does not identify a point in time. Also, what if I don't know yet where I will be and I want to set a reminder for a particular date and time?
cwillu 1y ago
If I set my cellphone alarm to go off at 6am, and it goes off at 8am instead “because it's currently 6am in new york”, the alarm clock fucked up.
burntsushi 1y ago
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.

OskarS 1y ago

> No, I think it's very important to understand that local times in the future do not identify a point in time and that local times are not necessarily tied to any particular location. I mean, they sometimes do. You might want to wake up at 7.00 AM in the morning regardless of what timezone you’re in, but if I ask Siri what time sunrise is tomorrow (very relevant for setting my alarm!) she better give it to me in local time taking time zones into account. Another example: I’ve added all the F1 races and qualifications this year to my calendar (I’m a big fan) so I can easily check that the Italian Grand Prix at Monza starts today at 3.00 PM my local time. If I travel to another timezone, my calendar better adjust, or else I’ll miss the races.

fauigerzigerk 1y ago
That's my whole point really. We need both points in time and (date)times that are relative to some possibly unknown location. These concepts cannot be merged.

rendaw 1y ago

You wouldn't use a datetime for an alarm clock, just a time. The timezone is implicit in the appointment, it's the timezone of the place you're making the appointment at. Scrapping DST is built into the timezone database IIRC, as are other timezone shifts. In the SQL example way above, the database is probably assuming UTC, which would make the datetime math give incorrect results (ex: around dst changes) if you interpreted it naively as a local time. This feels like a very Chesterton's Fence thread.

fauigerzigerk 1y ago
>The timezone is implicit in the appointment, it's the timezone of the place you're making the appointment at. Yes, but we cannot know which timezone that will be or how it will be defined and therefore we cannot store this appointment as a point in time. This is what we're talking about, right? Can we store all datetimes as points in time or not? I'm convinced that we cannot always do that because there are datetime semantics that cannot be expressed in that way. [Edit] >You wouldn't use a datetime for an alarm clock, just a time You should tell Apple that. They somehow managed to get this wrong. And I suspect the reason may be that many developers really really want all (date)time specifications to be points in time. They are not.
- mattclarkdotnet 1y ago
  Of course you want to be able to say 03:00 Europe/London for calendar appointments. Which it is true is not a timezone, and needs to be stored separately from the date time identifier…
  - fauigerzigerk 1y ago
    Exactly. Maybe it's not clear what my point is. Some people insist on the idea that all date/time specifications can be stored as points in time. This is what I'm disputing.
    - omnicognate 1y ago

jwr 1y ago

You seem to assume that "local" is defined and does not change over time. Well I travel a lot, and my "local" could be different next month. Without timezone information I have no idea what a timestamp represents.

fauigerzigerk 1y ago
>You seem to assume that "local" is defined and does not change over time. On the contrary, what I'm saying is that we need to be able to store date/time specifications that do not (yet) identify a point in time. Of course we also need to be able to store actual points in time. "Local" is a pretty vague term. I can refer to a specific place or to an as yet unknown place.