Comment by rocqua | Hacker News Reader

Comment by rocqua | Hacker News Reader

Parent Full thread

Some probing questions:

Alice and Bob both live in England and have planned a conference call at 15:00 on 4-jan. Now Alice happens to travel, and she is in American on 4-jan. What should here calendar do? Moreover, Alice also has a recurring event "Workout" every friday at 9:00, what should that shift to? Finally, it turns out Bob is also in America, what time should the conference call be at now? Finally, for some reason England or America decides to change the DST changeover will now happen on 3-jan.

There is no universal semantics of time that will deal with every case. Certainly 'store UTC and convert to the users's time-zone' is not universal, nor is 'store every timestamp with a time-zone'. The way people perceive of 'do this thing at this time' is very hard to capture. Moreover I'd wager no users would actually fill out time with sufficient detail to deal with this. "What do you mean UTC, time-zone, or local-time" I just wanna work out at 9:00 every day, and meet with Alice at 15:00 in a few days. I thought computers were meant to make things easy".

Unix timestamps have an extremely strict definition and should not be left up to interpretation.

You're describing UI/UX challenges with calendaring and appointments. Very real issues, but separate from Unix timestamps.

In your case, you're not doing the specific thing I prohibited. I only meant you should never do arithmetic on a timestamp to try to "convert" it to an equivalent representation of the same instant (as Java 8 defines it) in another timezone. However you're specifically doing arithmetic on the timestamp to calculate a new different instant, which is fine. (Your case isn't that different than the user pressing a "shift this event time by N hours" button.)

However, I saw a good tip once that you should only store timestamps of past events and events that happen at a fixed instant regardless of calendars and wall clocks as Unix timestamps. Timestamps for things like future calendar appointments (that may be affected by future changes in regions' timezone definitions) should be stored as a date and wall clock time and regional timezone, and only converted to a Unix timestamp when it happens. This makes it possible to see the timezone the user intended, let it be changed, and works well even if timezones themselves change before the event happens.

> you should only store timestamps of past events and events that happen at a fixed instant regardless of calendars and wall clocks as Unix timestamps

I think this works more often than not, but it's hardly foolproof or without repercussions. Say, you can imagine Google Calendar having a list of holidays for the US. Say it's New Year's day. You're saying you'd replicate that into 6 epoch timestamps (one per time zone in the US) per year in the past, instead of just storing it as "January 1, 00:00:00, recurring every year"?

This is a trick question - for whole-day events, the best way to handle them is to record the calendar day you want them to happen on, not the timestamps of the start and end of the day in some particular timezone. See what iCal does with DATE versus DATE-TIME (which must be UTC or include TZ): https://tools.ietf.org/html/rfc5545#section-3.3.4

"Whole-day event" is a red herring. You could've just as easily wanted an event for the first hour of New Year's day rather than for the whole day.

Yes. This sounds a bit silly for New Year in particular because its timing is slightly less arbitrary than other holidays', but holidays move around: https://en.wikipedia.org/wiki/Uniform_Monday_Holiday_Act

It's not "a bit silly", it's ridiculous. It's one uniform holiday in the entire country, recurring at a particular time on a particular calendar day. That's how it's defined, so that's how you record it. If it gets moved one day then you change the recurrence rule from that point forward. The rule you wan't isn't "turn past timestamps into epoch time", it's "record timestamps with their correct semantics for the situation".

I really agree, especially with "There is no universal semantics that will deal with every case." When I enter a time for an appointment, then travel to a different TZ, but know I'll be home when the meeting occurs, I have to tolerate the Macintosh calendar converting my meeting to the local TZ, then back to my local TZ, which ends up being odd at least, and confusing and annoying when it first happened.

Reply on news.ycombinator.com