6 ms·

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 appo

by 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
      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).
      - fauigerzigerk 1y ago
        What is my incorrect conclusion? What I'm saying is that we cannot reliably store a future local time such as "13:00 on the 12th Sept 2025 Europe/London" as an instant in time.
        omnicognate 1y ago
        No but we can and should store it as a timestamp with a timezone. It is rare for a nominal (date)time to be the correct thing to use. Please do read my other comment.
        fauigerzigerk 1y ago
        >No but we can and should store it as a timestamp with a timezone. It would be highly unusual and misleading to call something a timestamp unless it is a point in time. In Postgres for instance, the timestamp with timezone type represents an instant in time. This data type cannot be used to store things like reminders for future appointments. It's not rare at all.
        akio 1y ago
        That is not quite right. In Postgres, timestamptz (aka timestamp with time zone) represents an instant in time. timestamp (aka timestamp without time zone) represents what you are calling local time. timestamp (without time zone) is exactly what you should use to store future appointments. Something that often trips people up is that they think timestamptz stores a timestamp plus a time zone (probably because of its unfortunate name). It does not; it always stores a Unix epoch without an extra time zone, converting any zoned timestamp that it is passed.
- frizlab 1y ago
  I don’t know what’s your beef against Apple but the alarm clock does use a local time (though there have been (unacceptable) bugs leading to incorrect wake up time due to DST).
  - fauigerzigerk 1y ago
    I may misremember as it happened years ago. I thought it was the alarm clock but it's possible that it was an event reminder for an appointment that went off at the incorrect local time.
    - frizlab 1y ago
      Calendar has an option to enable/disable time zone support, but that’s not a very well-known option…
  - dotancohen 1y ago
    Those bugs are the leaked implementation detail that the alarm clock does in fact store the time zone internally.
    - frizlab 1y ago
      It is possible, but I’m honestly not convinced.
- omnicognate 1y ago
  The vast majority of them really should be points in time. The correct name for a (date)time that isn't is a "nominal" or "naive" date(time), not a local one. Nominal (date)times do indeed have valid use cases, but they are rare. Taking your example of an appointment, a nominal (date)time would be appropriate if the meeting were to take place at a particular local time but in an as-yet unspecified geographical location, which will be specified later. The form of the appointment would be "we will meet at 13:00 according to the local convention in the place where the meeting actually happens, which is yet to be determined". Here, a nominal time would be appropriate, but note that it would need to be paired with some geographical information prior to the appointment taking place in order to identify a point in time, allowing the meeting to go ahead. The above is a very unusual situation, though. It's far more likely that the meeting will be either in a location known up front or in no particular location (eg. if it's a video call with participants in multiple countries). In the first case, the correct thing is to include the geographical timezone of the location where the meeting will take place. For example, if the meeting is in London the timezone would be Europe/London. You raise the concern that the local convention could change, eg. daylight saving time could be abolished, but that isn't an issue. The "whatever the convention is in operation in London at that time" part is captured in the use of Europe/London as the timezone, and there would be no need to update the (date)time if the convention changes. The (date)time identifies an instant in time as long as the convention doesn't change, but if the convention does change it automatically reflects it. In the second case we need to define an instant in time so that people know when to attend the meeting. This could be done with a count of milliseconds from an agreed reference instant, but that's not very user friendly. The correct thing to use here is a (date)time with a defined timezone. If there really is no favoured location UTC would be the obvious choice, but any preferred timezone could be used as long as it's indicated in the (date)time so that the specific instant can be resolved. You might want to avoid using a zone like "Europe/London" whose convention could potentially change, although if you did use it the instant at which to to connect would still be well defined at the time of the meeting. You rightly point out that nominal datetimes don't define instants in time, but that's why you should avoid them. Most use cases should specify a point in time, at least up to local convention in a specific location. Genuine use cases for nominal (date)times are rare. In the vast majority of cases where they are used a timezone really should have been specified. This mistake is extremely common, and it doesn't remotely surprise me if some programmers at Apple have made it. A brief note on "local" times. These aren't the same thing as nominal times. A local time has an implicit timezone that is the local one according to the current locale. Local (date)times therefore do specify particular instants in time. One of the biggest mistakes people make is to write out local (date)times as nominal (date)times to stores that can be read by code running with different locales. This causes many problems. If you write out a local (date)time include the current time zone! I ask you please to learn from the above. I know it's hard to prevent comment exchanges turning into arguments, but I'm not trying to win points here. I've taken a chunk of my Sunday morning to explain something I don't find terribly exciting in the hope that the knowledge will benefit anyone who reads it. I really hate being in a situation where I have a timestamp from a log or db or on the wire or something and whoever put it there didn't think to include the information needed to interpret it correctly. It happens to me distressingly often at work. Let's all do better. Edit: Worth noting that ISO 8601 doesn't allow timezones like Europe/London. That's disappointing but doesn't relieve you of the duty to include the timezone information when persisting (date)times. It just makes it slightly more awkward. Good date/time libraries do support these zones.
kelnos 1y ago
> The timezone is implicit in the appointment, it's the timezone of the place you're making the appointment at. That's not necessarily the case, though. The location is implicit (or explicit, I guess) in the appointment, but the timezone may have changed by the time the appointment arrives. Say for example, your region decides to stop doing daylight saving time changes. But it's just your region, not the entire existing time zone, so a new zone is created to reflect that.
- deleted 1y ago
  [deleted]
- progval 1y ago
  It depends on how you identify a timezone. If you use an IANA identifier then short of a war it's pretty safe that the place of the appointment will use the same IANA timezone; because those follow changes in DST rules and even changes in offsets.

by rendaw 1y ago

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
    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).
    - fauigerzigerk 1y ago
      What is my incorrect conclusion? What I'm saying is that we cannot reliably store a future local time such as "13:00 on the 12th Sept 2025 Europe/London" as an instant in time.
      - omnicognate 1y ago
        No but we can and should store it as a timestamp with a timezone. It is rare for a nominal (date)time to be the correct thing to use. Please do read my other comment.
        fauigerzigerk 1y ago
        >No but we can and should store it as a timestamp with a timezone. It would be highly unusual and misleading to call something a timestamp unless it is a point in time. In Postgres for instance, the timestamp with timezone type represents an instant in time. This data type cannot be used to store things like reminders for future appointments. It's not rare at all.
        akio 1y ago
        That is not quite right. In Postgres, timestamptz (aka timestamp with time zone) represents an instant in time. timestamp (aka timestamp without time zone) represents what you are calling local time. timestamp (without time zone) is exactly what you should use to store future appointments. Something that often trips people up is that they think timestamptz stores a timestamp plus a time zone (probably because of its unfortunate name). It does not; it always stores a Unix epoch without an extra time zone, converting any zoned timestamp that it is passed.
frizlab 1y ago
I don’t know what’s your beef against Apple but the alarm clock does use a local time (though there have been (unacceptable) bugs leading to incorrect wake up time due to DST).
- fauigerzigerk 1y ago
  I may misremember as it happened years ago. I thought it was the alarm clock but it's possible that it was an event reminder for an appointment that went off at the incorrect local time.
  - frizlab 1y ago
    Calendar has an option to enable/disable time zone support, but that’s not a very well-known option…
- dotancohen 1y ago
  Those bugs are the leaked implementation detail that the alarm clock does in fact store the time zone internally.
  - frizlab 1y ago
    It is possible, but I’m honestly not convinced.
omnicognate 1y ago
The vast majority of them really should be points in time. The correct name for a (date)time that isn't is a "nominal" or "naive" date(time), not a local one. Nominal (date)times do indeed have valid use cases, but they are rare. Taking your example of an appointment, a nominal (date)time would be appropriate if the meeting were to take place at a particular local time but in an as-yet unspecified geographical location, which will be specified later. The form of the appointment would be "we will meet at 13:00 according to the local convention in the place where the meeting actually happens, which is yet to be determined". Here, a nominal time would be appropriate, but note that it would need to be paired with some geographical information prior to the appointment taking place in order to identify a point in time, allowing the meeting to go ahead. The above is a very unusual situation, though. It's far more likely that the meeting will be either in a location known up front or in no particular location (eg. if it's a video call with participants in multiple countries). In the first case, the correct thing is to include the geographical timezone of the location where the meeting will take place. For example, if the meeting is in London the timezone would be Europe/London. You raise the concern that the local convention could change, eg. daylight saving time could be abolished, but that isn't an issue. The "whatever the convention is in operation in London at that time" part is captured in the use of Europe/London as the timezone, and there would be no need to update the (date)time if the convention changes. The (date)time identifies an instant in time as long as the convention doesn't change, but if the convention does change it automatically reflects it. In the second case we need to define an instant in time so that people know when to attend the meeting. This could be done with a count of milliseconds from an agreed reference instant, but that's not very user friendly. The correct thing to use here is a (date)time with a defined timezone. If there really is no favoured location UTC would be the obvious choice, but any preferred timezone could be used as long as it's indicated in the (date)time so that the specific instant can be resolved. You might want to avoid using a zone like "Europe/London" whose convention could potentially change, although if you did use it the instant at which to to connect would still be well defined at the time of the meeting. You rightly point out that nominal datetimes don't define instants in time, but that's why you should avoid them. Most use cases should specify a point in time, at least up to local convention in a specific location. Genuine use cases for nominal (date)times are rare. In the vast majority of cases where they are used a timezone really should have been specified. This mistake is extremely common, and it doesn't remotely surprise me if some programmers at Apple have made it. A brief note on "local" times. These aren't the same thing as nominal times. A local time has an implicit timezone that is the local one according to the current locale. Local (date)times therefore do specify particular instants in time. One of the biggest mistakes people make is to write out local (date)times as nominal (date)times to stores that can be read by code running with different locales. This causes many problems. If you write out a local (date)time include the current time zone! I ask you please to learn from the above. I know it's hard to prevent comment exchanges turning into arguments, but I'm not trying to win points here. I've taken a chunk of my Sunday morning to explain something I don't find terribly exciting in the hope that the knowledge will benefit anyone who reads it. I really hate being in a situation where I have a timestamp from a log or db or on the wire or something and whoever put it there didn't think to include the information needed to interpret it correctly. It happens to me distressingly often at work. Let's all do better. Edit: Worth noting that ISO 8601 doesn't allow timezones like Europe/London. That's disappointing but doesn't relieve you of the duty to include the timezone information when persisting (date)times. It just makes it slightly more awkward. Good date/time libraries do support these zones.

kelnos 1y ago

> The timezone is implicit in the appointment, it's the timezone of the place you're making the appointment at. That's not necessarily the case, though. The location is implicit (or explicit, I guess) in the appointment, but the timezone may have changed by the time the appointment arrives. Say for example, your region decides to stop doing daylight saving time changes. But it's just your region, not the entire existing time zone, so a new zone is created to reflect that.

deleted 1y ago
[deleted]
progval 1y ago
It depends on how you identify a timezone. If you use an IANA identifier then short of a war it's pretty safe that the place of the appointment will use the same IANA timezone; because those follow changes in DST rules and even changes in offsets.