Comment by powvans | Hacker News Reader

Comment by powvans | Hacker News Reader

I've spent the last several years developing applications that have calendaring at the core, where users collaborate across timezones, and where proper timezone handling is expected.

Just try to explain to everyday people just how hard the problem is, the technical in and out, the practical miracle that it all works in almost all the cases, that all the error prone complexity can be eliminated by acknowledging that it's the same time everywhere all the time. They will not understand and they will not care. They will most likely consider you crazy. Like Don Quixote tilting at windmills.

We implement technical solutions to hard problems in order to simplify daily life for the 99.9% of people who do not care about things like timezones. Not withstanding the elimination of DST, this article is asking for the opposite. Furthermore, behind the scenes we already deal with time in the agreed upon standard.

If your dates are not stored in UTC in your database, you are doing it wrong. If your API and client software do not deal in dates in UTC, you are doing it wrong. If your dates are not localized when displayed to end users, you probably have very unhappy users.

In my experience it's better to store local time (where the event physically happens) with a named timezone. That way when daylight saving laws change with 3 weeks notice you can adjust without shifting events (cough Outlook). UTC can be calculated easily if needed.

I can see how this could work for recording timestamps as they happen, or for events that have already happened. In this case, you still need to keep around the tables of time zone changes if you ever want to compare two timestamps.

How do you handle future timestamps when time zone data changes? Update all future timestamps? Keep a separate timestamp recording the timestamp at which the future timestamp was last updated?

Storing timestamps at UTC solves this at the expense of knowing how to view the timestamp at a specific time zone.

That's exactly the point, but the other way around.

If the timestamp is defined in local time (e.g. "a meeting is scheduled for 15:00 every second thursday") and you generate a list of the next events as UTC, and then the DST rules change, you have to go in and fix all the UTC timestamps for future events.

If you store local time + timezone name, the stored time doesn't have to change, and if you need it in UTC for display you can calculate it on the fly, using the most recent rules you know.

If intervals are more important (e.g. do something every 30 minutes, or exactly every 24 hours), then UTC is better, or if you are recording events as they happen.

You're right. For future events it does make sense to record the local time zone. Thanks for the clear explanation.

This is a really good point and I don't disagree with it. I'd tend to prefer to store in UTC and store the associated timezone separately.

The problem with that is you don't know what UTC is going to be in the future for a certain place and time.

> I'd tend to prefer to store in UTC and store the associated timezone separately.

This is exactly the wrong approach for calendaring software, because it results in appointments moving in time when governments change the daylight saving time rules.

Storing in a local time (plus time zone) is exactly right for calendaring. And the correct-sounding, but wrong, mantra of "always store in UTC" is why calendaring apps handled the change so poorly.

Depends on where you're storing it. If you're using a sensible RDMS like Postgres, there's a 'Timestamp with Time Zone' data type which will internally store the time as UTC but keep track of the offset for you.

The thing to remember, the critical part of data modelling things like this: a timezone is a property of a location, not of a timestamp.

Oddly, when working with calendar events, I found UTC to be unhelpful. In particular, consider the case of seeing an alarm for Friday at noon. If I happen to be traveling across the country this week, I don't want to remake my alarm.

This is more problematic for recurring events. If I set a weekly meeting at 11, I do not want it to move just because daylight savings time.

>Just try to explain to everyday people just how hard the problem is

A bit off topic but Computerphile / Tom Scott did an excellent video doing that https://www.youtube.com/watch?v=-5wpm-gesOY

Except when you over-localize. It really annoys me when I am away for the weekend and my calender thinks all my appointments are an hour later/earlier than they actually are.

Reply on news.ycombinator.com