Eugene van der Pijll wrote:
>For every future leap second, there will be a version of DT that
>handles it correctly. That the current implementation can not, is only
>an implentation problem :-).
Having the implementation thus permanently buggy seems like a bad idea.
Also, the version of DT that someone is using might not even know about
leap seconds that have already happened. You'll get different answers
from different versions, not just at different times.
>Seriously, for problems like "2030-06-30T23:59:59Z + 1 second = ????",
>you need to make an assumption about future leap seconds.
I think the only correct approach is to assume nothing and answer "I
don't know".
> That is a
>decision that may not be appreciated by the users of our modules that
>are not as familiar with leap seconds as you.
I think to do date arithmetic around possible future leap seconds you
need to either represent the uncertainty or have the user say what
assumptions to make. It would be nice to be able to represent the time
of a hypothetical future leap second, if I want to guess about when they
might be and schedule events for them. Generally I think this falls
under the rubric of giving DT a more sophisticated model of time-of-day.
> We should not perhaps be calling our time scale
>"utc"; but that would again be hard to explain to ordinary users.
How times change. When the POSIX time_t stuff was being written, the
knowledgeable people on the committee who wanted to write in terms of
"UTC" were (for a while) overruled by those who didn't want to confuse
readers with unfamiliar acronyms. They wanted to stick with their nice,
familiar (and wrong) "GMT".
I think you should at least document how your time scale goes. It'd be
better to give DT knowledge of multiple time scales.
>At the *end* of a leap second? That seems counterintuitive, but if you
>say so... This would mean that the jd value of time points during the
>leap seconds appear to belong to the next day.
Yes, it works that way. See, if I represent a UTC time as a tuple of
(mjdn, ssm), where ssm is "seconds since midnight", the calculation goes
MJD[UTC] = mjdn + ssm/86400
The discontinuity is at the end of the day. Also think about a negative
leap: the discontinuity is there also at the end of the day, only 86399
s since midnight. We don't wait until 86400 s since midnight, 1 s after
midnight of the next day, to jump the MJD. There actually were negative
leaps in the rubber seconds era. Btw, in the rubber seconds era the
ssm used in this calculation is UTC seconds, not TAI seconds.
>By the way, it seems that my DT::F::E::JD module gets this right.
Since, as I said, it's a slightly ill-defined concept anyway, "right"
is not so much any particular behaviour, but rather documenting exactly
what you do. Anything that mixes JD and UTC really needs to document
how it maps between them.
-zefram
