5 ms·

We spent weeks on this for our new conference calling app to determine when a user says "Setup a call at 10am for my group every week" that come October 29th 20

We spent weeks on this for our new conference calling app to determine when a user says "Setup a call at 10am for my group every week" that come October 29th 2018 the call takes place at 10am, not 9am following a DST change. After a heckuva lotta research and reading we determined that we needed to store the scheduled meeting time using two values; the local datetime and the desired timezone eg. scheduledAt: 2018-05-29T23:41:16.167 scheduledAtZone: Europe/London Everything else in the system like created, updated, ended data is stored using UTC and transposed on the client using the user's stored time zone preference. eg. createdAt: 2018-05-29T22:41:16.167Z The application server your app is running on of course needs to run on Etc/UTC but with that in place (so far...touch wood) we haven't had a problem in our usage.

0x0 8y ago
Yep, that's my conclusion too: storing timestamps for events in the past and up to present time - unix timestamp with optional tzid, and re-calculate local time formatting from scratch for display every time. Events in the future, do the opposite: store as yyyymmddhhiiss + tzid, and re-calculate utc from scratch for calculations every time. As a rule of thumb, at least.
- ithkuil 8y ago
  Interesting. And at some point the future becomes the past and you have to switch the representation and freeze it. Not trivial.
cryptonector 8y ago
You also need to periodically compute the next event, but you can't do it too far in advance. You have to do it close enough to the event that that you can adjust to timezone definition changes. Hopefully you don't have to think about leap seconds.
- acqq 8y ago
  Why would anybody schedule events in local time to happen on leap seconds?
  - amptorn 8y ago
    To make sure you covered those edge cases correctly!
    - acqq 8y ago
      The best coverage is not introducing special cases where they aren’t relevant.
  - simonh 8y ago
    If it's say a scheduler for an application, you might have an activity that occurs every x seconds. At a previous job events like that were often scheduled such that x was a different prime number for each task, in order to minimize regular simultaneous executions. A system like that could easily end up with tasks running on a leap-second.
    - acqq 8y ago
      Your example isn’t scheduling in local time but in system time. In local time would be “my meeting starts at xxx”. Leap seconds schould not be involved there, and neither the system time. The users aren’t going to be glad you’re doing that.
amptorn 8y ago
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."
cesarb 8y ago
> store the scheduled meeting time using two values; the local datetime and the desired timezone How does that work when the same local datetime happens twice during a DST switch, or when a local datetime is skipped during the other side of a DST switch?

0x0 8y ago

Yep, that's my conclusion too: storing timestamps for events in the past and up to present time - unix timestamp with optional tzid, and re-calculate local time formatting from scratch for display every time. Events in the future, do the opposite: store as yyyymmddhhiiss + tzid, and re-calculate utc from scratch for calculations every time. As a rule of thumb, at least.

ithkuil 8y ago
Interesting. And at some point the future becomes the past and you have to switch the representation and freeze it. Not trivial.

cryptonector 8y ago

You also need to periodically compute the next event, but you can't do it too far in advance. You have to do it close enough to the event that that you can adjust to timezone definition changes. Hopefully you don't have to think about leap seconds.

acqq 8y ago
Why would anybody schedule events in local time to happen on leap seconds?
- amptorn 8y ago
  To make sure you covered those edge cases correctly!
  - acqq 8y ago
    The best coverage is not introducing special cases where they aren’t relevant.
- simonh 8y ago
  If it's say a scheduler for an application, you might have an activity that occurs every x seconds. At a previous job events like that were often scheduled such that x was a different prime number for each task, in order to minimize regular simultaneous executions. A system like that could easily end up with tasks running on a leap-second.
  - acqq 8y ago
    Your example isn’t scheduling in local time but in system time. In local time would be “my meeting starts at xxx”. Leap seconds schould not be involved there, and neither the system time. The users aren’t going to be glad you’re doing that.

amptorn 8y ago

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."

cesarb 8y ago

> store the scheduled meeting time using two values; the local datetime and the desired timezone How does that work when the same local datetime happens twice during a DST switch, or when a local datetime is skipped during the other side of a DST switch?