6 ms·

This kind of thing becomes a lot of fun when you're trying to schedule a regular international call between e.g. the US and the UK, where the offset in hours ch

This kind of thing becomes a lot of fun when you're trying to schedule a regular international call between e.g. the US and the UK, where the offset in hours changes four times per year because their daylight saving adjustments are not simultaneous. When I say "becomes a lot of fun" what I actually mean is that this observation lets us understand very quickly that the problem is not generally solvable. One way or another, somebody's 9 o'clock meeting is going to suddenly take place at 10. Having accepted that, we can push through the idealism and start working actual solutions like the one you described - have the user attach the regularly scheduled meeting time specifically to the UK or to the US.

ithkuil 8y ago
> [..] regularly scheduled meeting time specifically to the UK or to the US very funny things happen when there is a shared physical resource e.g. a booked meeting room, and you have a bunch of people schedule meetings with different reference time zones. ah, and if you think this creates havoc only for a the few weeks while the TZs are out of sync, remember that in the southern hemisphere DST is applied in "reverse"
- caf 8y ago
  Oh, that's fun: "A change in the definition of a timezone has caused previously non-conflicting bookings to conflict."
  - ithkuil 8y ago
    well, technically the "funny" aspect I was talking about, was the things that happened once the meeting room booking has conflicted and two group of people clashed both claiming that their booking was more right (as opposed to "how funny this can happen" in the first place). It's also interesting that since this doesn't happen frequently enough it's usually hard to develop a good way to get out of it.
    - caf 8y ago
      I think I'd resolve it by saying that any bookings made in a timezone that has changed its definition will be cancelled if the new definition causes the booking to conflict with another (including the case where two or more timezones have changed simultaneously: all involved bookings attached to changing timezones are cancelled). "The timezone you have used to define this booking has been altered, and the booking cannot be updated due to unavailability of the resource XXXX. Please choose a new time for this booking."
      - ithkuil 8y ago
        yeah, and given that in most times such change is well known in advance, the software could help dealing with it in the least disruptive way!
  - seanp2k2 8y ago
    Yep, time zones are lame and we’d be much better off if everyone just got used to saying the time in UTC. But then an “9 to 5” would become a “regular 8-hour shift” and be less fun to talk about, school might let out at 0300, and the times would vary when it’s dark / light out, which would probably be too much for the average joe to handle.
    - rspeele 8y ago
      Also depending where you live, it might become the next calendar day in mid-afternoon. Imagine: "Want to meet up Friday?" ... "You mean tomorrow afternoon, or the morning after that?"
    - eXpl0it3r 8y ago
      Everyone on UTC is really just useful for scheduling stuff internationally and just because of that, telling everyone to change their daily life, so you have it a bit easier, doesn't seem like the right plan. Additionally, timezones aren't really the big issue, it's more the changing of timezones due to DST or similar is what's causing the biggest issue. Getting rid of DST looks like a lot better solution for everyone.
      - petre 8y ago
        The worst thing about DST is that it breaks the linearity of time, allowing for it to skip back and forth and causing all sorts of problems such as "missing" and "empty" hours. In my country the train stops for one hour at the spring DST change and just waits for time to pass to account for the "missing" hour and not mess up the schedules by arriving one hour earlier.
    - rkuykendall-com 8y ago
      Eh, people would keep saying 9-to-5 and post in Future-Reddit "TIL 9-to-5 jobs are called that because in the early 21st century 9am was defined as when the work-day started" or something else equally half-right.
      - caf 8y ago
leonroy 8y ago
> This kind of thing becomes a lot of fun when you're trying to schedule a regular international call Heheh, exactly. We're currently debating how best to implement this since this one is more a UI issue than a UTC/Time issue. For example if the user wants to schedule a call at 2pm New York time (UTC-4) we need to show them the consequences of dialling a participant in the UK (UTC+1) and even more so someone in Sydney (UTC+10). If you use your ZonedDateTime classes carefully in your code (or equivalents if not using Java) then your app does take care of the DST changes. You can then show the user the scheduled time for not just the person making the creating the event but for every participant - ultimately the user has to decide what compromise to make when scheduling events across time zones and DST changes.
vidarh 8y ago
I've generally decided to just avoid scheduling calls for the working week before and after the DST switchover, because I never remember which of the UK and US switches first, and in which direction, and so many other people mess it up too. Of course, not everyone has that luxury of avoiding calls...
nucleardog 8y ago
I live near a border crossing thats opening hours are set in the time zone on the other side. My side doesn't observe DST. The other side does. The border keeps different Summer and Winter hours. Trying to figure out when I need to leave to make sure I get to the border during its open hours to get through, and then when I need to leave (in local time on the other side) to get back through during the open hours is an extremely tedious problem. Worst part is crossing the border is just me driving South. My longitude doesn't really change.
petre 8y ago
Well, Morocco changes its DST four times per year so that during Ramadan the night (and subsequently lunchtine) falls earlier. Time is an illusion. Lunchtime doubly so. — Douglas Adams

ithkuil 8y ago

> [..] regularly scheduled meeting time specifically to the UK or to the US very funny things happen when there is a shared physical resource e.g. a booked meeting room, and you have a bunch of people schedule meetings with different reference time zones. ah, and if you think this creates havoc only for a the few weeks while the TZs are out of sync, remember that in the southern hemisphere DST is applied in "reverse"

caf 8y ago
Oh, that's fun: "A change in the definition of a timezone has caused previously non-conflicting bookings to conflict."
- ithkuil 8y ago
  well, technically the "funny" aspect I was talking about, was the things that happened once the meeting room booking has conflicted and two group of people clashed both claiming that their booking was more right (as opposed to "how funny this can happen" in the first place). It's also interesting that since this doesn't happen frequently enough it's usually hard to develop a good way to get out of it.
  - caf 8y ago
    I think I'd resolve it by saying that any bookings made in a timezone that has changed its definition will be cancelled if the new definition causes the booking to conflict with another (including the case where two or more timezones have changed simultaneously: all involved bookings attached to changing timezones are cancelled). "The timezone you have used to define this booking has been altered, and the booking cannot be updated due to unavailability of the resource XXXX. Please choose a new time for this booking."
    - ithkuil 8y ago
      yeah, and given that in most times such change is well known in advance, the software could help dealing with it in the least disruptive way!
- seanp2k2 8y ago
  Yep, time zones are lame and we’d be much better off if everyone just got used to saying the time in UTC. But then an “9 to 5” would become a “regular 8-hour shift” and be less fun to talk about, school might let out at 0300, and the times would vary when it’s dark / light out, which would probably be too much for the average joe to handle.
  - rspeele 8y ago
    Also depending where you live, it might become the next calendar day in mid-afternoon. Imagine: "Want to meet up Friday?" ... "You mean tomorrow afternoon, or the morning after that?"
  - eXpl0it3r 8y ago
    Everyone on UTC is really just useful for scheduling stuff internationally and just because of that, telling everyone to change their daily life, so you have it a bit easier, doesn't seem like the right plan. Additionally, timezones aren't really the big issue, it's more the changing of timezones due to DST or similar is what's causing the biggest issue. Getting rid of DST looks like a lot better solution for everyone.
    - petre 8y ago
      The worst thing about DST is that it breaks the linearity of time, allowing for it to skip back and forth and causing all sorts of problems such as "missing" and "empty" hours. In my country the train stops for one hour at the spring DST change and just waits for time to pass to account for the "missing" hour and not mess up the schedules by arriving one hour earlier.
  - rkuykendall-com 8y ago
    Eh, people would keep saying 9-to-5 and post in Future-Reddit "TIL 9-to-5 jobs are called that because in the early 21st century 9am was defined as when the work-day started" or something else equally half-right.
    - caf 8y ago

leonroy 8y ago

> This kind of thing becomes a lot of fun when you're trying to schedule a regular international call Heheh, exactly. We're currently debating how best to implement this since this one is more a UI issue than a UTC/Time issue. For example if the user wants to schedule a call at 2pm New York time (UTC-4) we need to show them the consequences of dialling a participant in the UK (UTC+1) and even more so someone in Sydney (UTC+10). If you use your ZonedDateTime classes carefully in your code (or equivalents if not using Java) then your app does take care of the DST changes. You can then show the user the scheduled time for not just the person making the creating the event but for every participant - ultimately the user has to decide what compromise to make when scheduling events across time zones and DST changes.

vidarh 8y ago

I've generally decided to just avoid scheduling calls for the working week before and after the DST switchover, because I never remember which of the UK and US switches first, and in which direction, and so many other people mess it up too. Of course, not everyone has that luxury of avoiding calls...

nucleardog 8y ago

I live near a border crossing thats opening hours are set in the time zone on the other side. My side doesn't observe DST. The other side does. The border keeps different Summer and Winter hours. Trying to figure out when I need to leave to make sure I get to the border during its open hours to get through, and then when I need to leave (in local time on the other side) to get back through during the open hours is an extremely tedious problem. Worst part is crossing the border is just me driving South. My longitude doesn't really change.

petre 8y ago

Well, Morocco changes its DST four times per year so that during Ramadan the night (and subsequently lunchtine) falls earlier. Time is an illusion. Lunchtime doubly so. — Douglas Adams