Live data from Hacker News

Falsehoods Programmers believe about Time

infiniteundo.com

121–130 of 222 posts

Re: Falsehoods Programmers believe about Time

#121

"7. 7.A week (or a month) always begins and ends in the same year." Not sure what the (or a month) is doing there. I'm pretty sure the end of december is the end of the year and the beginning of January is the beginning of the year. A month can't span multiple years...can it?

You are right. I said "a month" but I meant something more like "a period of 28 days" or "a month-long period." I'll think about how to word this more clearly.

Re: Falsehoods Programmers believe about Time

#122
post #82

"The smallest unit of time is a milli/second" seems a bit silly, as it really depends on your application. Is he expecting programmers to implement time in Planck units?

It's not uncommon for languages and libraries to assume that millis are the smallest resolution. Java is getting better, but is still pretty hit or miss. But if you're writing performance sensitive code you're definitely in micros and maybe in high nanos. There's a lot of those in a millisecond.

Re: Falsehoods Programmers believe about Time

#123
post #105
post #70

Earlier quoted context omitted.

It isn't? Can you explain that in a bit more detail?

Some examples that come to mind: 1) You're (possibly) assuming that both timestamps come from the same machine. They could be from two machines (Server timestamps a transaction start, client timestamps the end.) Clocks are not accurate, so the delta time is not correct. 2) Time A is before a DST change forward or back, Time B is after. Delta would be wrong by +/- 1 hour (assuming all other factors are tracking with a…

#4 is why you really should be using ntpd(8): after syncronization, NTP will try to slew the clock if the difference is less than 128ms, step it if it's offset is between 128ms and 1000ms, and will exit with an error if the offset changes to be greater than 1000ms.

Re: Falsehoods Programmers believe about Time

#125
post #116
post #71

Earlier quoted context omitted.

N+9.1: Non leap years will never contain a leap day. http://support.microsoft.com/kb/214326

But that's a bug in Excel. "Non leap years will never contain a leap day" is true.

It was a bug in Lotus 1-2-3 that was intentionally implemented into Excel, so technically it was a backwards-compatibility "feature". And some items from the original list aren't exactly "truths" as much as implementations or configurations, e.g.

> 19. The system clock will never be set to a time that is in the distant past or the far future.

> 20. Time has no beginning and no end.

Re: Falsehoods Programmers believe about Time

#126
post #74

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

IMHO you will change your tune with more time and experience; numerics are often more portable and unambiguous than string or serialized-object alternatives... e.g., if you pass around datetimes as "int64 count of 100-ns intervals since 1-1-1601 UTC" there is little opportunity for someone who doesn't know how to use it to get a quasi-usable yet incorrect datetime out of it.

Also note, there are plenty of database systems that either have no proper datetime datatype, or have primarily datetimes that include no TZ info.

Re: Falsehoods Programmers believe about Time

#127
post #8

Who believes these things? February is always 28 days long? Any 24-hour period will always begin and end in the same day (or week, or month)? A week always begins and ends in the same month?

Bugs happen. Especially thoughtless ones.

The title might better have been "Things programmers have tried to do with time."

Re: Falsehoods Programmers believe about Time

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

Let's keep some perspective. The vast majority of software applications don't use dates from the 18th century so it's fine to for your app to assume that the Gregorian calendar always was and always will be.

Re: Falsehoods Programmers believe about Time

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

I think that for the vast majority of real-world software applications JodaTime is bloated and unnecessary.

Most applications need only three 'classes' to represent time:

1. A timestamp (ie. number of milliseconds since midnight on 1 January 1970 GMT)

2. A Gregorian Date (ie. three numbers representing day, month, year)

3. A TimeZone (to convert between 1 and 2)

In Java the first and third types are perfectly represented by java.util.Date and java.util.TimeZone. The second class can be represented by something like this: http://calendardate.sourceforge.net/

(Disclaimer: I wrote CalendarDate)

Post reply on HN