@martinjuckes wrote: > Rather than create a kludgy fix in the standard, couldn't we provide people > with clearer guidance? The leap seconds are not that complicated .... though > it took be a while to get the information and it be useful to make that bit > easier for our users, e.g. the authorise IETF list of leap seconds is here .. > and this list will be updated at least 6 months before a new leap seconds is > introduced.
I have to agree with Jim here -- guidance is not the problem -- UTC is well defined, and as you say the leap seconds are published, and the math is not that hard. The problem is libraries: no datetime library that I know of handles leap seconds properly (OK -- I just googled, how hard is that :-) -- the BoostDatetime lib does handle leap seconds). So I'll rephrase, "no datetime library commonly used by the CF community" handles leap seconds. As a community, maybe we could do something about that, but as a data standard, we're stuck with the state of practice as it is. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/148#issuecomment-435152076
