5 ms·

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

• taeric 10y ago
  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.
• mkj 10y ago
  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.
  • grzm 10y ago
    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.
    • detaro 10y ago
      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.
      • grzm 10y ago
        You're right. For future events it does make sense to record the local time zone. Thanks for the clear explanation.
  • powvans 10y ago
    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.
    • mkj 10y ago
      The problem with that is you don't know what UTC is going to be in the future for a certain place and time.
    • jeff_tyrrill 10y ago
      > 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.
    • alfalfasprout 10y ago
      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.
  • jameshart 10y ago
    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.
• fdgdasfadsf 10y ago
  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.
• wtfishackernews 10y ago
  >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 https://www.youtube.com/watch?v=-5wpm-gesOY