Joshua Hoblitt wrote: >How is it buggy? In the same sense that it'll be fixed by a future version's knowledge of each future leap second. You not-seriously suggested that the incompleteness of the leap second list was merely a bug that would be fixed in a future version.
In reality it's not a bug for the list to be incomplete. It's a bug for it to treat the list as complete. >So what are you proposing? Modeling future leapseconds? There are so many ways to model them. Over the long term (centuries) it's possible to forecast approximately how many leap seconds will have occurred by then. Stating actual dates for them is right out, though. There are purposes for which this kind of estimate is useful. But I think it's a pretty specialised requirement. >I would really like to hear your solution to this problem. I don't have a solution, sorry. Only some vague thoughts. I think DateTime should probably provide more than one way to handle unknown leap seconds. The user ought to be able to say "do this calculation assuming an average of one leap second every 500 days over this period". The user also ought to be able to say "I need an exact answer, so complain if the answer depends on leap seconds that you don't know about". I think on correctness grounds the default behaviour should not make any assumptions at all about unknown leap seconds. And I think it all needs to be documented, whatever the behaviour is. -zefram
