Comment by geuis | Hacker News Reader

Comment by geuis | Hacker News Reader

Parent Full thread

"Timezones are a presentation-layer problem! Most of your code shouldn't be dealing with timezones or local time, it should be passing Unix time around."

I can attest to this. At a previous job our entire API used UTC. It was clean and worked at every layer of the app, from django to our client-side javascript. When we needed to display a human readable version, we did the translation at render time. All interactions with time as data was done with the UTC timestamp and saved much headache.

A couple months before I left, one of the engineers proposed switching everything over to a textual representation according to ISO_8601. I forget the nature of the argument, but it was inane(to me). This actually led an extensive back/forth email exchange between various members of engineering, me as one of the frontend engineers, and even the engineering manager who seemed to favor the idea.

I argued, "why change the entire stack which works just fine, etc etc". Fortunately, in this instance a heavy workload and group apathy about taking on unnecessary additional work allowed this entire concept to wither and disappear after a couple days.

Though, in calendar apps, I find this behavior annoying. My phone automatically adjusts my calendar when I change timezones, but I put all events into my calendar as local time for wherever I will be when that event is going to occur. I don't want to have to think about how to enter things into my calendar when I'm planning a trip back to where I grew up...

Well, this is also a presentation layer problem. You should be able to tell it to use your home zone instead of the current local zone, for example.

I don't want to tell it that though. I just want to enter things at a time, and have them stay at that time.

You have to tell it a time zone or else the calendar app will not know what time you mean (and really, time without a time zone is meaningless). What you are doing is using your current time zone as the default so when you enter appointments from another time zone you're actually entering them incorrectly.

Any calendar app should allow the entry of appointments with time zone.

> You have to tell it a time zone or else the calendar app will not know what time you mean

It seems logical to me that whatever time I write in my calendar app is the time that I expect something to happen. I.e. it is the local time at wherever I happen to be. If I put in a meeting at 4pm on 8/7/2011, then I expect an alarm to sound whenever the local time is 4pm on 8/7/2011.

That's how my paper diary works (or used to work when I had one) - if I am planning for a future event where I will be in a different time zone, I simply write down the local time of the event.

That doesn't sound at all logical to me. The phone conference is scheduled for a particular time, eg 10am in Montreal. The other meeting participants do not care that it is now 10am in Mombasa, where your phone happens to be at the moment - they will not be at the meeting for another 7 hours anyway.

Your other way also allows for the same event to happen twice, at different times, which is entirely unexpected.

Yes, very true. Doesn't work very well for events where people are attending from multiple time zones. I was thinking more of events that I attend in person.

But I'll use the paper diary example again - if I was in Mombassa and was due to have a phone conference at 10am Montreal time, I would write "6pm - Phone conference" in my diary (assuming that is indeed the correct local time).

And in your example, yes, it would be easier for me if I could tell my calendar that it is "10am, montreal time, please adjust that to mombassa time". So I guess my ideal solution would be a calendar app that works the way I described unless I specifically override it.

Anyway, I think this proves the point that time is hard.

Alternatively, we could all just use UTC+0 and never worry about time zones again! :)

Most useful calendar apps these days allow you to share events, or invite others to an event. What happens when you invite someone who lives in another timezone? There's no good way to handle this that doesn't involve taking timezones into consideration.

What is supposed to happen when you take a flight at 4:10pm on 8/7/2011 and land before 4:10pm on 8/7/2011 (local time)? Do you get the alarm twice?

I think that would be the expectation of most non-engineers, assuming they set the new time zone before arriving and if they even considered edge cases like that. It's also how most alarms work, whether mechanical or digital.

I think that's pretty hard to do in these post-concord days?

Though if you lived close to a time zone border it could be a problem. There are towns straddling the Queensland-New South Wales border in Australia. There is a one hour time difference between the states for half of the year (NSW does daylight saving, QLD does not). I've always wondered how local businesses deal with that.

It is incredibly easy to arrive hours before you leave. Just fly East across the dateline (like Aus to North America).

And I've even lost a birthday flying back in the other direction. Great scheduling, that.

> It is incredibly easy to arrive hours before you leave. Just fly East across the dateline (like Aus to North America).

Or use a fast plane going west (Concorde used to take ~3h for London to NYC, and NYC is on UTC-5, so passengers on Concorde would arrive "2h before they left").

Time without a time zone is not meaningless. I don't need my calendar to be aware of when in the day the other side of the phone call is happening. I just want to enter "Dinner at 8pm" and have dinner stay at 8pm. This is one situation where I do not want my computer to get unnecessarily smarter than me. Just DWIM.

It still depends on where you have the dinner. If you have a dinner at 8pm in UK, you could leave France after 8pm and arrive for your dinner at 8pm again. What would you expect to happen - get the alarm twice?

What if you actually wanted to call someone before their dinner and that's why you put the event in? If that person was in France in this scenario, you'd want to call them before 7pm UK time instead. Calendars can't guess the context - location of the event depends completely on what you put in.

Any calendar app either has to base its time zone on location or ask you to manually choose a zone. How would you propose changing this?

i think what is being suggested is something like storing it as a string and raising the alarm when the string matches the current local time. so it's "time in whatever time zone i am local to when it matches the time".

(which has problems with uniqueness, but does seem like an intuitive "dwim" high level interface).

In the realm of unrealistic-now-but-maybe-cool-later, if it could access your flight reservations, it could infer where you'll be at the time and base the time zone on that.

Calendar has to know where each event occurs in order to present time in event timezone which introduces some interesting issues like: 1) requiring location fatigues UX, 2) inferring location is not always possible and frequently wrong, and 3) tracking location requires more data like complete travel plans. Adding to this just-another-presentation-layer problem, online event timezones are different for each participant.

Yup. In our architecture (TVs and other devices) time is kept as UTC through the entire system - We actually have two APIs. One that is UTC time that is used in all middleware.. and a "GetCurrentTime" API that is used only in the presentation layer to know how time should be displayed on screen. GetTime returns UTC time getCurrentTime returns a time struct of hours / minutes / seconds... This works well and it allows developers to easily identify API misuse during code reviews.

Storing all your time as UTC can create problems depending on what you're doing with the time. If your application is a calendaring application and people can book things well into the future, you can have problems with daylight saving time and timezones this way.

For my most recent app, timestamps are UTC and everything else is stored local time.

You'll need to store the time zone along with the local time, otherwise you won't be able to handle the situation where you have multiple users in different time zones. About the only reason this is preferable to storing UTC along with time zone, is because there are sometimes political decisions made to change daylight savings time (i.e. the mere fact of DST/TZs etc. isn't enough).

Yes, I store the timezone (associated with the user) along with the local time. All date operations in the application are done related to their timezone.

Storing it this way is preferable because it makes working with times across DST boundaries a non-existent problem. DST is a pain in the ass and you want to use whatever language / database facilities to exist to make this as smooth as possible -- storing local time (and setting the timezone appropriately) makes it not your problem. Also users frequently set their own timezone incorrectly, and when they fix their timezone, they don't want all their appointments to be at the wrong time.

A calendar application is a bit different, since the whole subject of the application is time, time zones, etc. Still I'd store all in UTC along with the user's time zone (you'd have to store the time zone anyway with localized time too).

Storing local time is preferable because it makes working with times across DST boundaries a non-existent problem and because users frequently set their own timezone incorrectly.

I've done previous projects where I've stored UTC dates or unix timestamps for this situation and it was a hassle to deal with. You really need to consider the nature of the data -- for straight forward timestamps (like the date of a post) UTC makes the most sense. For user-entered dates, I think local time is much more appropriate and a lot simpler.

Don't you get exactly the same problem when you store timezones? CET always stays == UTC + 1 hour. So there's no difference whether you store 8 CET or 7 UTC, because some country may decide it's not in CET at that time anymore... Only storing the actual location would save you if you're thinking about dates in far future.

Then again, you'd have to somehow verify what's the time in that location at that point.

I don't store timezone offsets, I store the timezone strings and they are pretty granular. Users can choose the most appropriate timezone from 448 possibilities.

What about when you're storing things at a date/hour/or even minute granularity.. not seconds.. is this still as important?

We solved this by storing metadata around the timestamps. For us, it was an ID that referenced a global table of polities that use daylight savings and we could derive the current GMT offset from that. We could theoretically update the polities table over time as these changed, though while I was there we never did.

As for granularity, you can derive day/minute/hour etc based on the timestamp. For us, we were able to do those calculations in the application layer. For other types of projects, you can store that data in the db if you need to do more efficient queries for example.

Reply on news.ycombinator.com