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 adjusts by an hour.
N+6. Months have either 28, 29, 30, or 31 days.
N+7. The day of the month always advances contiguously from N to either N+1 or 1, with no discontinuities.
Explanations:
(N)-(N+2): There exist enough jurisdictions in the world that time zone changes occur often enough to require regular updates to the time zone database, more frequently than many distribution release schedules occur.
(N+3)-(N+5): Jurisdictions change DST policies even more frequently than they change time zones.
(N+6)-(N+7): September 1752 had 19 days: 1, 2, 14, 15, ..., 29, 30.
> 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.
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.
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.
My favorite eye-stabby example of this was parsing RSS feeds (with meaningless timezone abbreviations!) from sites in the southern hemisphere. Depending on the date and various last-minute laws (thank you, President Chavez), the differential would be 0, +1, +2, +2.5 or +3 hours between various points.
Actually, almost no country outside the British Empire (and not even Scotland inside it) implemented the Gregorian reform at the same time. Britain was pretty late in doing so, too.
As for "all modern computer systems", Unix time is completely ignorant about anything except seconds.
> Unix time is completely ignorant about anything except seconds
That's not correct, actually: UNIX time tracks UTC instead of TAI meaning it "corrects" for leap seconds. As a result, UNIX time is not "the number of seconds since epoch" but "86400 * (number of whole days since epoch) + (number of seconds since midnight)", and UNIX time will go forwards (never so far) and backwards on leap seconds (a second will repeat in most implementations as the day goes from 23:59:60 to 00:00:00, as they have the same timestamp).
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 part was that this was in Javascript (and obviously he was not using a timeout). The entire page would lock up while it waited for the second to elapse. He never even figured out the obvious usability concern because he was so confounded by the fact that the procedure wasn't getting called after a second had passed.
Ok, to be fair, it was a freshman year programming class - not an unexpected or even unusual mistake. But it gave me a chuckle just now remembering it.
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!
This was hilarious for people who had booked tickets on flights out on the 30th. Do you leave on the 29th or the 31st...? This was a real problem for the airlines and headache for a number of travellers.
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)
