I've been on an airplane (on the flight deck - pre 2001) watching the sun rise in the West. Sometimes local time runs backwards.
Falsehoods Programmers believe about Time
51–60 of 222 posts
Re: Falsehoods Programmers believe about Time
#5239. The next day after 3 Sep 1752 is 4 Sep 1752.
I love that people in this thread think the adoption of the Gregorian calendar happened on a single date, it's way more complex than that.
Re: Falsehoods Programmers believe about Time
#53Earlier quoted context omitted.
That will stress it a bit, but to really torture it, see if it accepts 2012 June 30 23:59:60
Or June 1st 1905 00:02:00 in Singapore.
I had to google this one. http://www.timeanddate.com/worldclock/clockchange.html?n=236...
Re: Falsehoods Programmers believe about Time
#5435. Two timezones that differ, will differ by an integer number of hours.
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 the list hasn't actually covered the Gregorian calendar at all, since many people may not know the actual leap year rule.
N+9. There is a leap year every year divisible by 4.
The actual rule is that there is a leap year every year divisible by 4, except those divisible by 100, with a further exception to that exception for years divisible by 400, (so there is a leap year on such years). The year 2000 is one such year divisible by 400, so we have not yet passed a year divisible by 4 which is not a leap year since the invention of computers.
Re: Falsehoods Programmers believe about Time
#55If 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
Well, you don't know if 31.12.2015 will have a 23:59:60 or no. These seconds are announced just prior to being added, the system couln't possibly know it.
Re: Falsehoods Programmers believe about Time
#56You didn't mention any assumptions that get screwed up by the presence of leap seconds.
N. There are 60 seconds in every minute. N+1. UNIX timestamps always advance monotonically.
Re: Falsehoods Programmers believe about Time
#5735. People will just assume all APIs and standard libs that deal with dates are sane Adobe managed to build a pretty shitty Date object for ActionScript that takes days as a 1-indexed parameter, but months as 0-indexed. Hopefully ActionScript is not used in banking [1] [1] http://help.adobe.com/en_US/FlashPlatform/reference/actionsc...
This is not that insane, or at least relatively insane, because this matches the behavior of localtime(). I have heard the reason for using a 0-indexed month is for the convenience of mapping to an enum of month names.
Re: Falsehoods Programmers believe about Time
#5835. Two timezones that differ, will differ by an integer number of hours.
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…
N+8. It will be easy to calculate the duration of x number of hours and minutes from a particular point in time.
The reason this is impossible on Windows and downright awkward on Unix is because DST changes from time to time. Unless you have something like tzinfo, you cannot work out a particular date and time by merely adding a duration to another date and time in the past.
Instead, you must work out the timezone you are doing the calculation in, then work out whether the duration needs to incorporate a DST change, which involves working out what that DST changeover date and time was...
Of course, it's impossible on Windows because Microsoft only give the start and end datetime offsets for the current year. Amazingly, after all the patches they've had to issue to fix DST changes over the years, they still haven't implemented a Windows equivalent of tzinfo yet. And may never do so, even though they really aught to, given they are one of the leaders in calendaring software.
Re: Falsehoods Programmers believe about Time
#59Earlier quoted context omitted.
39. If you create two date objects right beside each other, they'll represent the same time. (a fantastic Heisenbug generator) 40. You can wait for the clock to reach exactly HH:MM:SS by sampling once a second.
I'm not sure this counts as a constructive comment, but an interesting anecdote anyway - an early coding partner of mine once wrote a procedure he expected to run once exactly every second by continuously polling the time in a while/do_nothing loop until exactly one second had passed. It took some convincing to get him to accept that try as he might, it was very unlikely that "==" was what he wanted there. The best p…
Somewhat related, but I've seen a lot of retry-with-a-timeout loops that will either throw a spurious timeout error or wait for a very long time if the system clock just happens to jump at the right time.
Another amusing anecdote: I got an old PowerBook out of storage and booted it up. The battery had run flat, so the clock reset to 1970. Spotlight noticed this and decided it had to reindex the entire drive. At some point during all of this, NTP kicked in and reset the clock to the correct year. I wanted to see how long Spotlight would take to finish indexing, so I popped down the menu. The progress bar indicated that it was about halfway done, and based on how long it had taken so far, it estimated that only another 40 years would be required to finish!
Re: Falsehoods Programmers believe about Time
#60Also, time is unidirectional.
I think this would be better stated as, "the system clock increases monotonically".