Thread.sleep(1000) sleeps for 1000 milliseconds.
Falsehoods Programmers believe about Time
101–110 of 222 posts
Re: Falsehoods Programmers believe about Time
#102This 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…
> 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.
In Unix-land, this data type and boatload of library functions is the operating system. The system provides and deals with local time conversion when necessary. If your application isn't very involved with time (eg. it's not a calendar or scheduling application) then it is sensible to use Unix timestamps.
This ties you to a Unix OS, which isn't usually too bad a decision since other more important things do as well. On the other hand, using your programming language or database ties you to that database or language, which is arguably worse.
Re: Falsehoods Programmers believe about Time
#103About #7: doesn't a month always end in the same year it started?
The way you're thinking about it, yes -- but the passage of a month may take you from December the [mumbleth] to January the [mumbleth], which are in different years. For some strange reason, code in the wild doesn't always account for that, so the due date for an item may well be eleven months before the request was entered.
One I caught recently: The difference between the current time and one week from the current time is not always 7 * 86400 seconds.
By noticing an automated test that failed 2 weeks out of the year.
Re: Falsehoods Programmers believe about Time
#104A meta-misconception: It's possible to establish a total ordering on timestamps that is useful outside your system.
Virtual machines can be screwed with comprehensively. So can non-virtual ones, come to that, and your software likely isn't in a position to tell that it's already seen 02:34:17 GMT 2013-05-25 five times already.
So what can you do about that? Bloody nothing. Absolutely nothing whatsoever. You're screwed. Everything you could do can be screwed with in ways your program can't defend against.
The lesson: Don't worry about bugs you can't fix. Refusing to play games you can't win will keep your hair in your head a lot better than knowing the intricacies of human timekeeping systems past and present.
Re: Falsehoods Programmers believe about Time
#105How about, "the difference between two timestamps is an accurate measure of the time that elapsed between them".
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 accuracy.
3) Both times are taken on the same machine, but far enough apart that clock drift plays a factor.
4) Both times are taken on the same machine, but an ntptimesync cron job kicked off in between them and adjusted the system clock.
Re: Falsehoods Programmers believe about Time
#106I was reading this and realizing that he was mixing two very different things: design considerations and design errors. Treating every year as 365 days is a design error. Leap years will break it. "Timezones next to eachother don't require changes of more than 1 hr" might also doom that F22 flying across the international date line (ok, I am assuming that was more of a test assumption than a code assumption).
On the other hand, requiring that clocks be set to within, say, five minutes (Kerberos 5) is a design consideration. This is why Kerberos is usually used with something like NTP.
But beyond this there are a lot of things you can't do (like expire cookies) if you don't assume that client and server have similar times on their clocks. Sometimes it makes sense to require things you can't assume to always be true.
Re: Falsehoods Programmers believe about Time
#10735. Two timezones that differ, will differ by an integer number of hours.
36: Continguous timezones are no more than an hour apart. (aka we don't need to test what happens to the avionics when you fly over the International Date Line)
Re: Falsehoods Programmers believe about Time
#108Earlier 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. In the British Empire, anyway.
Corrollary: The same month has the same number of days in it everywhere!
Re: Falsehoods Programmers believe about Time
#109I've been on an airplane (on the flight deck - pre 2001) watching the sun rise in the West. Sometimes local time runs backwards.
So, were you on the Concorde, or was it a Tu-144?
Re: Falsehoods Programmers believe about Time
#110And 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…
Also, computer systems have different Gregorian calendars. Your system could use the proper Gregorian calendar and a system you're communicating with could be using the proleptic Gregorian calendar. Most people don't notice the difference because dates aren't frequently slung around < 1582 in the modern world, but if a system has an idea of an "unset" date being equal to 1/1/1 it could lead to an error if transmitted to the other, resulting in an invalid date 12/30/0.