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

41–50 of 133 posts

Re: What every programmer should know about time

#41

Post by oasisbob »

Unix time: Measured as the number of seconds since epoch (the beginning of 1970 in UTC). Unix time is not affected by time zones or daylight saving.

I don't think this is strictly correct. This implies that someone could start an atomic stopwatch at midnight on Jan 1, 1970, and it would match Unix time. It won't.

Because Unix time is non-linear and will either slew or repeat seconds when UTC has leap seconds, the hypothetical stopwatch would be ahead of Unix time by 34 seconds.

... at least this is how I understand it. Every time I try and wrap by head around the differences between UTC/TAI/UT1, my head really starts to hurt.

Re: What every programmer should know about time

#42

Post by petercooper »

UTC used to be called Greenwich Mean Time (GMT)

Sort of. This could be misleading because GMT and UTC are still two different things with different definitions. Wikipedia is a good source of info on this, but for starters:

UTC is closely related to Universal Time and Greenwich Mean Time (GMT) and within informal or casual contexts where sub-second precision is not required, it can be used interchangeably.

So not strictly, but practically.. ;-)

Re: What every programmer should know about time

#43

Post by Archaeum »

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

Re: What every programmer should know about time

#44

Post by sehugg »

Also beware storing milliseconds in 32-bit quantities (as if you'd ever! but it happens).

GetTickCount is the poster child for this class of bugs: http://en.wikipedia.org/wiki/GetTickCount

In fact some versions of Windows CE intentionally set this value to (0xffffffff - 10 minutes) before bootup so that bugs were more likely to come out in testing, rather than showing up 42 days after bootup.

Also, don't store time intervals as floating point, especially if you're working on a missile system: http://apps.ycombinator.com/item?id=1667060

Re: What every programmer should know about time

#46

Post by masklinn »

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

> incidentally, does anyone know of a really good API for time (including calendars etc)? python's (which is largely a thin layer over C) is a horrible mess, for example.

The only date & time API I've ever seen praised is Joda (JDK/Java library). Joda's author went on to redesign it from scratch (though with inspiration from his work on Joda) for JSR-310, Java's new Date and Time API.

Re: What every programmer should know about time

#47

Post by masklinn »

projectileboy wrote: post #15

I'd like to add one to the list - store your Unix time as a 64-bit value, to save your client/employer some headaches in 2032. I doubt I'm the only HN user who was spent a lot of time in '98 and '99 fixing Y2K problems.

> I'd like to add one to the list - store your Unix time as a 64-bit value

How about actually doing the right thing and using time_t?

Re: What every programmer should know about time

#48

Post by kijinbear »

oasisbob wrote: post #41

Unix time: Measured as the number of seconds since epoch (the beginning of 1970 in UTC). Unix time is not affected by time zones or daylight saving. I don't think this is strictly correct. This implies that someone could start an atomic stopwatch at midnight on Jan 1, 1970, and it would match Unix time. It won't. Because Unix time is non-linear and will either slew or repeat seconds when UTC has leap seconds, the hyp…

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

Re: What every programmer should know about time

#49

Post by bluedanieru »

kijinbear wrote: post #48
oasisbob wrote: post #41

Unix time: Measured as the number of seconds since epoch (the beginning of 1970 in UTC). Unix time is not affected by time zones or daylight saving. I don't think this is strictly correct. This implies that someone could start an atomic stopwatch at midnight on Jan 1, 1970, and it would match Unix time. It won't. Because Unix time is non-linear and will either slew or repeat seconds when UTC has leap seconds, the hyp…

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.

Re: What every programmer should know about time

#50

Post by ReturnTheGift »

altrego99 wrote: post #45

MySQL (at least 4.x and 5.x) stores DATETIME columns as a "YYYY-MM-DD HH:MM:SS" string Wow that's terrible!

And false. See lysol's reply or the 5.0 reference manual's section on storage requirements:

http://dev.mysql.com/doc/refman/5.0/en/storage-requirements....

"YYYY-MM-DD HH:MM:SS" is the format of the DATETIME datatype. That's all.

Post reply on HN