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

Falsehoods Programmers believe about Time

infiniteundo.com

Post reply on HN
Print view View original

71–80 of 222 posts

Re: Falsehoods Programmers believe about Time

#71

Post by hc5 »

lambda wrote: post #54
JoshTriplett wrote: post #34

Earlier quoted context omitted.

N. The offsets between two time zones will remain constant. N+1. OK, historical oddities aside, the offsets between two time zones won't change in the future . N+2. Changes in the offsets between time zones will occur with plenty of advance notice. N+3. Daylight savings time happens at the same time every year. N+4. Daylight savings time happens at the same time in every time zone. N+5. Daylight savings time always a…

> September 1752 had 19 days: 1, 2, 14, 15, ..., 29, 30. That's only in the British Empire. Other countries moved to the Gregorian Calendar at different times. It began being adopted on 15 October 1582 (the day after 4 October 1582) in some Roman Catholic countries (Spain, Portugal, Italy, Poland). Russia didn't switch until 1918. So, you could also have: N+8. There is only one calendar system in use at one time. And…

N+9.1: Non leap years will never contain a leap day.

http://support.microsoft.com/kb/214326

Re: Falsehoods Programmers believe about Time

#72

Post by henrikschroder »

arohner wrote: post #63

N+?? The time library in your programming language is correct. Every time library I've ever dealt with will have serious problems with at least one issue listed on the original article or in the comments here. JodaTime (on the JVM) is by far the best, but even they have problems, and are creating a new library to solve those.

> and are creating a new library to solve those.

Now they have N+1 problems.

Re: Falsehoods Programmers believe about Time

#74

Post by ams6110 »

This sort of stuff is why I scream "NNNNOOOOOOOOOOOOOO!!!!!!" when people store date/time as integers (i.e. "unix timestamps") when almost every database and programming language has a proper date or datetime data type, and a boatload of library functions that correctly compute differences between dates, handle leap years and time zones, etc. Well maybe not always correctly, but it's more likely that YOU will screw up your date math than it is that the well-tested date library will.

Re: Falsehoods Programmers believe about Time

#76

Post by snprbob86 »

brazzy wrote: post #31

And it doesn't even mention all the bizarre things that have been done (for reasons good and bad) to time by various governments. Like adjusting from local solar time to standard GMT offset timezones (which involves skipping a given number of minutes and seconds or having them twice). Or introducing/abolishing/moving around daylight savings time. Or "super daylight savings time" with a 2 hour offset. Or moving from o…

Yeah, this list is woefully incomplete. Here's another good read: http://naggum.no/lugm-time.html

Re: Falsehoods Programmers believe about Time

#77

Post by yxhuvud »

grimlck wrote: post #30
tomjen3 wrote: post #18

If you really want to stress test time handling code, try to get it to accept Feburary 29, 1900 and Feburary 29, 2000. The first doesn't exist but the second does. But really, with regards to time use whatever library came with you programming language.

That will stress it a bit, but to really torture it, see if it accepts 2012 June 30 23:59:60

Or 30th February 1712.

Re: Falsehoods Programmers believe about Time

#80

Post by yxhuvud »

morsch wrote: post #65
DanWaterworth wrote: post #45

How about, "the difference between two timestamps is an accurate measure of the time that elapsed between them".

What's wrong about that? Numerical issues due to the truncation (ie 2500ms → 2s) and subsequent subtraction? Leap seconds? Anything else?

Measurement error, and the fact that the timestamps may not be taken on the same machine.
Post reply on HN