Comment by JoshTriplett | Hacker News Reader

Comment by JoshTriplett | Hacker News Reader

Parent Full thread

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.

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.

For now.

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.

'items from the original list aren't exactly "truths" as much as implementations or configurations' QFT.

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.

> September 1752 had 19 days: 1, 2, 14, 15, ..., 29, 30.

In the British Empire, anyway.

From which many modern reckonings of time descend, including the one used by all modern computer systems.

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.

In hindsight, it seems like a brilliant decision.

But then we had to go and make it care about leap seconds...

Except it doesn't account for leap seconds.

Is that true? Isn't that the responsibility of the whatever component that translates the number of seconds since Jan 1 1970 into a calendar?

POSIX requires that the Unix timestamp value be incremented by exactly 86400 per day, regardless of how many seconds that day actually contained.

https://en.wikipedia.org/wiki/POSIX_time#Encoding_time_as_a_...

Unix time is not the number of seconds since Jan 1st 1970.

> 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).

Corrollary: The same month has the same number of days in it everywhere!

Reply on news.ycombinator.com