On Tuesday, November 16, 2010 13:00:17 Kagamin wrote: > Steve Teale Wrote: > > It also strikes me as odd that it does not include a table of leap > > seconds. As it stands, some of its methods could return values that were > > out by a year for up to four or five seconds on January 1 2011. I'm no > > expert on UTC, Gregorian Calendar and such, so I could well be wrong, > > but .... > > This depends on how the library imports time from system. If it imports in > nominal form: receives actual hours, minutes and seconds as separate > values, it will precisely represent the time point in nominal and string > forms. Only time intervals will be off by leap seconds that were > introduces during the intervals.
Of course, the annoying thing about leap seconds is that because they're unpredictable, it's _impossible_ to give correct interval lengths (with regards to leap seconds) for intervals which cover future dates. Right now, leap seconds introduce a difference of 24 seconds, and a new leap second has generally been added about once every two years, but that could easily change. A year or two from now, it could be pretty much any number within a few seconds of 24 (even numbers less than 24 like 22 or 23). So, only intervals entirely in the past can be completely correct with regards to leap seconds (or ones so near in the future that there's no way that a leap second would have been added or removed between now and then). Honestly, leap seconds are complete stupidity with regards to computers. They just complicate things. Of course, time in general has various issues when it comes to computers (DST is one of the stupidest ideas even IMHO; I don't even want to _think_ about how many bugs it's created), but leap seconds are definitely on my list of time-related stuff that should be abolished (and there are those lobbying for it, so it may happen eventually). On the bright side, computers generally ignore them, so you don't have to care (unless you're one of those extremely rare people who do, at which point, you have my condolences). - Jonathan M Davis
