Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What every programmer should know about time

unix4lyfe.org

Post reply on HN
Print view View original

51–60 of 133 posts

Re: What every programmer should know about time

#51

Post by yaix »

wvenable wrote: post #29
geuis wrote: post #2

"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…

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.

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).

Re: What every programmer should know about time

#52

Post by wvenable »

barrkel wrote: post #31
wvenable wrote: post #29

Earlier quoted context omitted.

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.

Re: What every programmer should know about time

#53

Post by dandelany »

stoney wrote: post #32
matwood wrote: post #21

Earlier quoted context omitted.

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…

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.

Re: What every programmer should know about time

#54

Post by wvenable »

yaix wrote: post #51
wvenable wrote: post #29

Earlier quoted context omitted.

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.

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.

Re: What every programmer should know about time

#55

Post by stoney »

caf wrote: post #35
stoney wrote: post #32

Earlier quoted context omitted.

> 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…

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.

Re: What every programmer should know about time

#56

Post by stoney »

chrisbolt wrote: post #39
stoney wrote: post #32

Earlier quoted context omitted.

> 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…

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'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.

Re: What every programmer should know about time

#59

Post by thristian »

bluedanieru wrote: post #49
kijinbear wrote: post #48

Earlier quoted context omitted.

You're right. It should say: Unix time is the number of seconds since epoch, not counting leap seconds.

Any idea why it was done this way? It seems like counting leap seconds belongs in the same layer as sorting out timezones, i.e. not here.

Because people working with timestamps like to write code that says things like:

    // schedule another run for tomorrow
    schedule_event(now() + 86400)
...which doesn't actually work when leap-seconds are involved (things start to drift by a second). If you specify that leap seconds get replayed, it works.
Post reply on HN