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

71–80 of 133 posts

Re: What every programmer should know about time

#71

Post by roel_v »

andrewcooke wrote: post #19
tseabrooks wrote: post #4

As someone working working on time sensitive code on embedded systems (DVRs that get UTC from the broadcast), I can certainly agree with the issues laid out in the post. As an example: We have some certifications our product must pass and the certification body plays a 4 minute looping broadcast stream with the test condition in it. It turns out I handled the time jump hat occurred when the stream would loop around p…

just to add to the examples here: last week i was writing code to handle calibration data from seismic detectors. these are connected to GPS receivers and so have pretty accurate times. yet when i triggered a calibration it would start 1 minute in the past. somehow the receiver was moving back in time before starting the calibration.... ...or ntpd on the test computer had failed and the machine was a minute fast :o)…

boost::date_time. I've cursed at it in the beginning, but it does things the Right Way, and I've been saved a number of times by its fighting back against shortcuts (like using Unix time - the issues identified in the article are real and a good summary, but the solution only works for the case where you need to work within a limited time span, from 1970 until a few decades into this century.)

Re: What every programmer should know about time

#72

Post by dirtyaura »

> Timezones are a presentation-layer problem!

I want to correct this common misconception that UTC is enough. Calendar time with all human traditions involved is more complex than a simple timestamp.

The advice above is incorrect for calendar and scheduling apps, or anything that has a concept of a repeating event.

An example: we have a weekly meeting occurring 9AM Monday in San Francisco. You are in London and want to attent the meeting over Skype. When is it in London time?

It depends.

On 7 Mar 2011 it's at 5pm

On 14 Mar 2011 it's at 6pm

On 29 Mar 2011 it's at 5pm

To make these calculations, you need to know timezone & daylight saving time (DST) rules of both your current location and the home location of the event.

A "DST zone" of a home location of a repeating event has to be saved together with a time and thus it's not just presentation-layer issue.

Re: What every programmer should know about time

#73

Post by wladimir »

jen_h wrote: post #26

"The system clock can, and will, jump backwards and forwards in time due to things outside of your control. Your program should be designed to survive this." This is one of my favorite go-to test cases. I've found some really fantastically interesting, catastrophic network halting badness with this really simple test.

This literally just happened to a VPS of mine. Time was jumping forwards and back, every second the time could jump an hour ahead and back. Everything screwed up, from log rotation to sessions.

My first thought was that this was some kind of prank :-) but seems it was a hardware issue on the parent machine combined with ntpd trying to compensate.

Re: What every programmer should know about time

#75

Post by roel_v »

Don't blindly follow the advice at the end of this article! The issues he identifies are real, but the 'solution' only work in a small subset of use cases. When one needs a longer time span than [1970-2038], Unix timestamp is horrible - how are you going to represent a date of birth in it for people born before 1970 (yes they do still exist!)? There is no guarantee that negative timestamps will work!

Also it doesn't take different calendars into account, still doesn't work with leap seconds, doesn't deal well with time spans (t1 - t2 specified in seconds can be a lot things in reality), ...

Use a proper date time library to deal with dates and store them in your database in a string format, including the time zone. It depends on your application which time zone (UTC or local), but in general UTC is best, and the local time zone could be a second column if you need the info (or it could be a property of the user, but e.g. many calendaring application then screw it up in the UI layer...)

I'd like to read a book on the UI issues associated with dates and times, anyone know of something like that?

Re: What every programmer should know about time

#76

Post by roel_v »

dirtyaura wrote: post #72

> Timezones are a presentation-layer problem! I want to correct this common misconception that UTC is enough. Calendar time with all human traditions involved is more complex than a simple timestamp. The advice above is incorrect for calendar and scheduling apps, or anything that has a concept of a repeating event. An example: we have a weekly meeting occurring 9AM Monday in San Francisco. You are in London and want…

Yes, very correct! I hope the 'lets just use Unix timestamp because it's easy' mentality will go away soon!

Re: What every programmer should know about time

#77

Post by Gonsalu »

dirtyaura wrote: post #72

> Timezones are a presentation-layer problem! I want to correct this common misconception that UTC is enough. Calendar time with all human traditions involved is more complex than a simple timestamp. The advice above is incorrect for calendar and scheduling apps, or anything that has a concept of a repeating event. An example: we have a weekly meeting occurring 9AM Monday in San Francisco. You are in London and want…

There is no need to save the home location with the time.

If you save the UTC date of the event, the localized date for some timezone can be extrapolated from it.

Re: What every programmer should know about time

#78

Post by peteretep »

dirtyaura wrote: post #72

> Timezones are a presentation-layer problem! I want to correct this common misconception that UTC is enough. Calendar time with all human traditions involved is more complex than a simple timestamp. The advice above is incorrect for calendar and scheduling apps, or anything that has a concept of a repeating event. An example: we have a weekly meeting occurring 9AM Monday in San Francisco. You are in London and want…

UTC is enough for - as the article suggests - storing a date.

Storing a recurring class of dates is - of course - more complicated; but then has anyone ever suggested otherwise?

Re: What every programmer should know about time

#79

Post by dirtyaura »

Gonsalu wrote: post #77
dirtyaura wrote: post #72

> Timezones are a presentation-layer problem! I want to correct this common misconception that UTC is enough. Calendar time with all human traditions involved is more complex than a simple timestamp. The advice above is incorrect for calendar and scheduling apps, or anything that has a concept of a repeating event. An example: we have a weekly meeting occurring 9AM Monday in San Francisco. You are in London and want…

There is no need to save the home location with the time. If you save the UTC date of the event, the localized date for some timezone can be extrapolated from it.

UTC is enough if we have a single instance of an event. If we have a concept of recurring event ("this event will occur on every Monday 9am"), then it's not enough.

I just wanted to highlight that "time" is a human concept that in informal setting means a lot of things, but when you start to model it formally, it can be more complex than a single timestamp.

Post reply on HN