What every programmer should know about time • Hacker News Board

Re: What every programmer should know about time

#101

Post by andrewcooke » Mon, Jul 04, 2011, 1:31 PM UTC

rvkennedy wrote: post #95

andrewcooke wrote: post #19

Earlier quoted context omitted.

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

Watch out for GPS time: it ignores leap seconds, and is currently, exactly fifteen seconds ahead of UTC.

thanks. currently everything is as insensitive to time as possible (during calibration the data are tagged, so i look for the block of tagged data near the correct time).

Re: What every programmer should know about time

#102

Post by CamperBob » Mon, Jul 04, 2011, 1:56 PM UTC

cbr wrote: post #96

CamperBob wrote: post #62

Earlier quoted context omitted.

You can store milliseconds in 32-bit quantities all you want, if you remember the One True Axiom of Time: never compare tick counts, always subtract and compare to the difference you were looking for. If you do it that way, you can't screw it up, at least in C.

Really? What if it wraps around? ts1=MAX_INT-40, ts2=20, ts2-ts1 < 0. Or does that actually work out correctly with signed integers in C?

It works regardless of signed/unsigned type, because signed ints still wrap at UINT_MAX (and not at INT_MAX).

Re: What every programmer should know about time

#103

Post by eru » Mon, Jul 04, 2011, 2:30 PM UTC

jrockway wrote: post #97

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…

The article should add a caveat: use UNIX time when you are recording the current time to store for later use. That can always be formatted in the user's current timezone to display back. When you're inventing a rule system based on local times, as you are above, of course you need to track the rules in the local time zone. That's because the rule is: "do this thing at 9am in my particular local time zone", not "do t…

As an aside, have you thought about the effects of DST on train schedules? In Germany, for example, they literally stop the trains for an hour when the clocks go backwards and let them all run a nominal hour late when they are going forward.

Re: What every programmer should know about time

#104

Post by qntm » Mon, Jul 04, 2011, 2:42 PM UTC

_urga wrote: post #87

In the future, the world will use UTC and sunrise and sunset will happen at different times, relative to where you are.

This seems like it would cause more problems than it solves.

"It's 10:00 here in London. I need to call someone in New York, what time is it there?" "10:00, same as it is everywhere in the world." "So... is now a good time to call them?" "I have no idea."

Re: What every programmer should know about time

#105

Post by georgefox » Mon, Jul 04, 2011, 3:07 PM UTC

adestefan wrote: post #98

_urga wrote: post #87

In the future, the world will use UTC and sunrise and sunset will happen at different times, relative to where you are.

No they won't. The idea that 12am is night and 12pm is day is pretty well entrenched in society.

While I understand your point, I find that a surprising number of people have issues with 12am vs. 12pm, often confusing the two. These same people tend to think midnight occurs at the end of the day.

Re: What every programmer should know about time

#106

Post by raleec » Mon, Jul 04, 2011, 3:08 PM UTC

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…

And not just for repeating events. I worked on an app that dealt with scheduling travel, and you needed to record the zone of both locales so that if a trip crossed time zones the trip length(which was derived) would remain accurate.

You also had to take into account what the DST would be for both locales at the scheduled time. Hint: Use Oracle, SQLServer doesn't have a way to stay updated with the constantly changing DST offsets worldwide..

Re: What every programmer should know about time

#107

Post by MarkMc » Mon, Jul 04, 2011, 3:38 PM UTC

The problem with time-based bugs is that they are often subtle. I've had time-based bugs that only appear between 11pm and midnight; or only during daylight savings time; or only where the client is in a different timezone to the server.

Also, it is very common for business applications to deal with 'dates in the calendar', for example: a) John's birthday is 26 August 1966 b) The loan was borrowed on 16 January 2006 and repaid on 9 September 2009.

I suspect most programmers will disagree with me, but in my experience it is NOT good practice to use a timestamp class to represent such things. It's better to use a class specifically designed to represent a date in the (Gregorian) calendar. In fact, I created an open-source Java class for this purpose: http://calendardate.sourceforge.net/

Re: What every programmer should know about time

#108

Post by angstrom » Mon, Jul 04, 2011, 4:26 PM UTC

jrockway wrote: post #97

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…

The article should add a caveat: use UNIX time when you are recording the current time to store for later use. That can always be formatted in the user's current timezone to display back. When you're inventing a rule system based on local times, as you are above, of course you need to track the rules in the local time zone. That's because the rule is: "do this thing at 9am in my particular local time zone", not "do t…

And that doesn't even get into the problem of the DST dates changing at the whim of legislation like it did recently in the US about 5 years ago. If you are attempting to track timezone instead of UTC you've now have to check date ranges when different DST was in effect. Very messy stuff. Better to just keep it in UTC or Unix if you need the offset it was recorded in as you mentioned.

Re: What every programmer should know about time

#109

Post by exDM69 » Mon, Jul 04, 2011, 5:59 PM UTC

roel_v wrote: post #71

andrewcooke wrote: post #19

Earlier quoted context omitted.

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

C++0x standard library is pretty nice too. std::chrono and std::thread work nicely together.

Right now I'm working with C, pthreads and struct timespec's and it makes me wish for a good time handling library.

Re: What every programmer should know about time

#110

Post by jrockway » Mon, Jul 04, 2011, 6:26 PM UTC

eru wrote: post #103

jrockway wrote: post #97

Earlier quoted context omitted.

The article should add a caveat: use UNIX time when you are recording the current time to store for later use. That can always be formatted in the user's current timezone to display back. When you're inventing a rule system based on local times, as you are above, of course you need to track the rules in the local time zone. That's because the rule is: "do this thing at 9am in my particular local time zone", not "do t…

As an aside, have you thought about the effects of DST on train schedules? In Germany, for example, they literally stop the trains for an hour when the clocks go backwards and let them all run a nominal hour late when they are going forward.

Very interesting. I didn't realize that an hour made much of a difference to Deutsche Bahn's schedules, however :)