Hacker News Reader

Comment by leonroy | Hacker News Reader

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.

View on HN

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.

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

Oh, that's fun: "A change in the definition of a timezone has caused previously non-conflicting bookings to conflict."

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.

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.

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.

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

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.

Then someone else would reply that it was actually because Government workers traditionally finished their work day at 4:51pm.

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.

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

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!

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

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.

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

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

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.

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

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.

Why would anybody schedule events in local time to happen on leap seconds?

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.

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.

To make sure you covered those edge cases correctly!

The best coverage is not introducing special cases where they aren’t relevant.

> 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?

Reply on news.ycombinator.com