On Mon, 19 Jul 2004, Eugene van der Pijll wrote: > UTC was not defined before 1972-01-01. In DateTime, "utc" is used as time > zone before 1972. The behaviour of our "utc" before 1972 is undefined, and > it's perfectly possible to have a leap second 1971-12-31T23:59:60.
Except that UTC is *defined* as being UTC-TAI = 10s on 1972-01-01. > The earlier time standard, UT, had a non-integer difference with TAI. It was > synchronised with the rotation of the earth regularly with the introduction > of fractional leap seconds. The difference between UT and UTC on 1971-12-31 > was about 0.2 seconds, IIRC, so if our "utc" is equal to UT before 1972, it > would be better to have no leap second in Dec 1971. UT1-UTC was -.0474900 on that date but regardless IERS did not declare a leap-second so our implementation is incorrect any way you look at it. > > A possible patch to correct this is attached. Are there any objections to > > this being committed? This could potentially break existing code but only > > because the current behavior is broken. > > This would probably have some effect on my DT::Format::TAI module, as I had > to correct for the extra second there. (But I can't check that at the > moment.) Still, I'm in favour of this correction. You mean DateTime::Format::Epoch::TAI64 or is there another module not on CPAN? Anyways, hopefully that's the only DateTime::* module that will have any breakage... I was more worried about end user code. Cheers, -J
