Chris wrote: > Once upon a time, unruh <[email protected]> said: >> Posix clearly has never even though about leapseconds, so their >> recommendations are pretty irrelevant. > > I wouldn't say they never thought about them; they made a choice to > avoid them because too much code assumes "(time()%86400)==0" means > midnight UTC, and leap seconds break that (making basic clock handling > much more complicated).
And once upon a time folks took liberties with calendar code, because leap-year handling was "more work". This was in the days when the internet was young and it took more effort to reasearch the correct algorithms, and then you had to code and test them properly. We're beyond *that* hurdle now... Remember Y2K? What about the discussions around the creation of difftime()? Folks used to like to dream about using simpler solutions there, too. I think it would be worth exploring some library functions to handle leapseconds in interval calculations and presentation. But I fully expect that folks will take the "easy" way out on this, as the pain/cost of a "better" solution is, frankly, not presently worth the effort. > At least on Linux, you can choose to have leap seconds, based on the > tzdata: > > $ TZ=UTC date -d @1230768023 > Thu Jan 1 00:00:23 UTC 2009 > $ TZ=right/UTC date -d @1230768023 > Wed Dec 31 23:59:60 UTC 2008 > > but that is just done in the timezone conversion, not the actual clock > handling. because the timescales are different. The timescale is a necessary part of the metadata. I think this overall situation is a case where "implied metadata" is biting us. Not surprising - there are costs in making the metadata explicit, and the status-quo is fine until it is not... In theory, practice and theory are the same. But in practice, they are not. H _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
