4 ms·

> But it would be nice to set a calendar event for "6pm London time", whatever London time happens to be when the event rolls around. But there's no standardise

> But it would be nice to set a calendar event for "6pm London time", whatever London time happens to be when the event rolls around. But there's no standardised interoperable way to say "2030-07-01 18:00:00 Europe/London". The only gotcha about such a thing is that there are ambiguous or impossible timestamps: 2023-11-05 01:30:00 America/New_York — that's one of two different times. For calendaring, it would make sense, since "same wall clock time regardless" is what most people want¹; there might be some UI difficulty/challenges to handle the weird times, and maybe one might want to have a way to specify a disambiguation in the syntax. Thankfully for calendaring those are usually in the middle of the night, but I've literally seen this happen in my career. ¹though once you invite the first person in a zone that doesn't do DST madness, note that this causes the calendar time to wobble on their calendars. Some of my international coworkers have to put up with this.

WirelessGigabit 3y ago
If I want a meeting at 9AM MST (Mountain Standard Time, which Phoenix observes year-round) then, when CA is on PDT (Pacific Daylight savings Time), they have the meeting at 9AM local time. But when CA switches to PST (Pacific Standard Time) the meeting shifts to 8AM for the people in CA. But if the people in CA lead, and always want the meeting at 9AM local time, then the meeting for the people in Phoenix will move from 9AM to 10AM and back. Can't have it all.
- wahern 3y ago
  In the OP's example, 2023-11-05 01:30:00 America/New_York, 1:30AM occurs twice as at 2:00AM the clock rolls back to 1:00AM. Normally this is resolved by including a disambiguating timezone, EDT (first 1:30AM) or EST (second 1:30AM). But if there's no timezone indication to accompany a geographical location, there's no way to disambiguate the time.
  - deathanatos 3y ago
    If there's no flag indicating DST. America/New_York is the timezone designation. Part of what makes TZ discussions incredibly difficult is that people play fast and loose with the terminology. I think the person you're responding to is simply saying that if you made the meeting in a non-DST observing zone, the meeting time would still wobble in a DST-observing zone. (I'm not sure why they're noting it, because my comment also clearly spells that out, too, albeit in reverse. But yes, it works both ways.)
  - jameshart 3y ago
    Right, to pick an actual time stamp for a particular local time in a particular location, you need to first choose at what time stamp to resolve the time offset for the location. Then in that time offset you can unambiguously map the localtime to a unique time stamp.
- deathanatos 3y ago
  I'm well aware. See the footnote. I know it works both ways, too, but probably would be better for the DST observing zone to deal with the effects of DST, instead of foisting such side effects onto our international friends.
- extraduder_ire 3y ago
  This is why I prefer, and try to use, "<time> <fine-location> time". Like: "Friday 6:30PM Vancouver time" and a world-clock to keep track of when that is. The website time.is is very useful for this. This takes a bit more effort, but it is less ambiguous and saves you from having to deal with the insanity that is time. DST switching will still cause issues but, as long as you're not the one cursed to implement that software, it should be fine with advance warning.
deleted 3y ago
[deleted]

WirelessGigabit 3y ago

If I want a meeting at 9AM MST (Mountain Standard Time, which Phoenix observes year-round) then, when CA is on PDT (Pacific Daylight savings Time), they have the meeting at 9AM local time. But when CA switches to PST (Pacific Standard Time) the meeting shifts to 8AM for the people in CA. But if the people in CA lead, and always want the meeting at 9AM local time, then the meeting for the people in Phoenix will move from 9AM to 10AM and back. Can't have it all.

wahern 3y ago
In the OP's example, 2023-11-05 01:30:00 America/New_York, 1:30AM occurs twice as at 2:00AM the clock rolls back to 1:00AM. Normally this is resolved by including a disambiguating timezone, EDT (first 1:30AM) or EST (second 1:30AM). But if there's no timezone indication to accompany a geographical location, there's no way to disambiguate the time.
- deathanatos 3y ago
  If there's no flag indicating DST. America/New_York is the timezone designation. Part of what makes TZ discussions incredibly difficult is that people play fast and loose with the terminology. I think the person you're responding to is simply saying that if you made the meeting in a non-DST observing zone, the meeting time would still wobble in a DST-observing zone. (I'm not sure why they're noting it, because my comment also clearly spells that out, too, albeit in reverse. But yes, it works both ways.)
- jameshart 3y ago
  Right, to pick an actual time stamp for a particular local time in a particular location, you need to first choose at what time stamp to resolve the time offset for the location. Then in that time offset you can unambiguously map the localtime to a unique time stamp.
deathanatos 3y ago
I'm well aware. See the footnote. I know it works both ways, too, but probably would be better for the DST observing zone to deal with the effects of DST, instead of foisting such side effects onto our international friends.
extraduder_ire 3y ago
This is why I prefer, and try to use, "<time> <fine-location> time". Like: "Friday 6:30PM Vancouver time" and a world-clock to keep track of when that is. The website time.is is very useful for this. This takes a bit more effort, but it is less ambiguous and saves you from having to deal with the insanity that is time. DST switching will still cause issues but, as long as you're not the one cursed to implement that software, it should be fine with advance warning.

deleted 3y ago

[deleted]