Hacker News Reader

Comment by skrebbel | Hacker News Reader

That doesn’t affect the point of the article at all though. Timezones change, so if you’re storing a datetime of something that happens at a particular physical place, store it with that place’s timezone (not offset)

(EDIT And even eg scheduled video calls take place in physical places, so in practice future events of any kind are best stored in localtime with the relevant user’s timezone attached)

View on HN

> scheduled video calls take place in physical places

have you ever travelled and had to join the call from a different country, different time zone? the calendars usually help you to translate the call's timezone to your local timezone, but they only can do that if they can determine the offsets.

Just convert using most up-to-date source time zone into UTC, then proceed as usual. The point is that the event is not actually fixed in time, but affected by local law that can arbitrarily move times of all scheduled meetings by an hour or so.

It would be nice if get get rid of DST so that we wouldn't have to special case situations that only happen once every half century, though.

Yeah so you determine the offset at display time. Store “Europe/Amsterdam”, not “UTC+1” so that if Amsterdam (or likelier, the Netherlands) decides to shift timezone or move the DST change dates or something insane like that, before the event occurs, you can trivially take that into account by updating to the newest tzdata file.

Converting from timezone to offset is a lossy conversion.

The most annoying case is when an event is already scheduled, and the timezone then changes. E.g. it is decided that from now on, DST will end a week later.

What to do with the events that were scheduled in that week before this change was known? One assumption is that the intent was to schedule it at the same time during the business day (the 9 o'clock meeting, lunch is at 12 etc.); but then you would've been better off storing local time with a location rather than even a timezone, as the (lack of) S in the timezone might not have been intentional.

I'm not saying you shouldn't use UTC though, I'm saying daylight savings is ludicrous and should be gotten rid off.

My personal taste is to store a day, a time, and a regional timezone (like Europe/Berlin) for calendar-like uses.

But even then, you'd need to notify those users who now have that in their own local calendars on the other side of the world... assuming they aren't using an electric attachment with the original TZ.

For example, working in a secure environment and putting certain events on a calendar manually on one side or the other.

> even eg scheduled video calls take place in physical places, so in practice future events of any kind are best stored in localtime with the relevant user’s timezone attached

I was in London when I scheduled a video call with someone in New York. When we actually took the call, I was in Spain and he was in Chicago.

I can’t think of any timezone that could have been attached to that meeting to make it useful at the time of creation. I absolutely expect my machine to be able to tell me what the local time of the meeting is when its timezone changes.

I move between time zones a few times a month. At some point time zone changes get annoying. I keep my work laptop and work phone on home time zone, and second phone autosyncs to local time zone.

I track meetings by notifications (2 hour prior etc)

This is possibly a better approach than I’m currently taking, thanks! I’ll try this on my next trip!

That only works if a timezone doesn't split in the future. Like a city in germany changes its timezone. Then the Europe/Berlin you've stored is wrong.

I admit, it unlikely, but it's been known to happen.

But you're storing a timestamp, so you can at least theoretically look up historical time zone rules based on place and time.

The only real problem would be geographic boundaries changing, e.g. two states currently sharing a time zone and DST rules diverging.

That's why the TZ database uses cities, not states or countries, to designate time zone information. It's still not bulletproof (not all cities exist in the TZ database obviously, and collecting that information can be very tricky too), but it's pretty good compared to the alternatives.

Reply on news.ycombinator.com