"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?
Falsehoods Programmers believe about Time
121–130 of 222 posts
Re: Falsehoods Programmers believe about Time
#122"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?
Re: Falsehoods Programmers believe about Time
#123Earlier 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…
Re: Falsehoods Programmers believe about Time
#124Re: Falsehoods Programmers believe about Time
#125Earlier 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.
> 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
#126This 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…
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
#127Who 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?
The title might better have been "Things programmers have tried to do with time."
Re: Falsehoods Programmers believe about Time
#128And 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…
Re: Falsehoods Programmers believe about Time
#129N+?? 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.
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)
Re: Falsehoods Programmers believe about Time
#130Can someone explain when this isn't true? Is he referring to leap seconds, or local timezone DST changes? Or something more interesting I'm failing to think of?