Support leap seconds?

[ChrisBarker-NOAA]

The next release of the CF standard will include a "UTC" calendar -- i.e. one that includes the UTC leap seconds.

However, it's an attractive nuisance at the moment, as there is very little software that supports leap seconds.

It would be nice if cftime did.

I'm not sure when I can find the time, but I would like to help write the code, if it's wanted.

[jswhit]

here's the discussion of leap seconds for CF: https://github.com/orgs/cf-convention/discussions/400

[larsbarring]

@ChrisBarker-NOAA asked me post some references that appeared in an email conversation. Here they are:

• Definitions of UTC, TAI, and Leap Seconds (Primary Standards):
  IERS Conventions (2010)
  Gérard Petit & Brian Luzum (eds.). IERS Technical Note No. 36,
  International Earth Rotation and Reference Systems Service, 2010.
  https://iers-conventions.obspm.fr/

• IERS Leap Second Bulletins, which is the source that "leap second aware" software build their awareness on:
  IERS Bulletin C (Leap Second Announcements).
  International Earth Rotation and Reference Systems Service.
  https://hpiers.obspm.fr/iers/bul/bulc/

• Internet RFC 7808 – “Unifying Leap Second Handling in Network Time Protocol (NTP)”:
  S. Mizrahi & T. Mayer (2016).
  IETF RFC 7808.
  https://datatracker.ietf.org/doc/rfc7808/

• Overview of leap seconds: implementations, use cases, problems, and future directions:
  Levine, J., Tavella, P., & Milton, M. (2023).
  “Towards a consensus on a continuous Coordinated Universal Time.”
  Metrologia, 60(2). https://doi.org/10.1088/1681-7575/acbc47

[jswhit]

If there is a use-case for this, I'd welcome a PR to implement it. I can't think of one at the moment.

[ChrisBarker-NOAA]

The use case is supporting the new UTC calendar about to be added to CF. Specifically for encoding / decoding observations recorded with UTC times.

There's currently a big chicken-egg problem with "proper" UTC (i.e. handling leap seconds) in that there's very little software that support it, so if providers create UTC encoded data, their end-users won't be able to decode it properly. :-(

I'm hoping adding it to cftime would provide one egg, anyway .. it's a start.

@larsbarring: any chance you might be able to work on this? I"m not even sure where to start! But a set of test cases would be a good start.

[ocefpaf]

I'm not an expert, in fact I know very little about the topic. With that said, would an implementation be something like a check against https://data.iana.org/time-zones/data/leap-seconds.list and then add/remove the second according to the table?

[ChrisBarker-NOAA]

Yes, exactly.

Note: it would be even better for this to be added to the Python standard library, but they've been hostile to the idea in the past :-(

[ocefpaf]

It seems that astropy implements this: https://docs.astropy.org/en/stable/_modules/astropy/utils/iers/iers.html#LeapSeconds

[ChrisBarker-NOAA]

Nice find! thanks!

And it looks like they use it in:

https://docs.astropy.org/en/stable/api/astropy.time.TimeDatetime.html#astropy.time.TimeDatetime.to_value

So maybe "all" we have to do is borrow that code.

(I don't think we want to depend on astropy ...)

[ChrisBarker-NOAA]

On a related note: the non-utc CF calendars do not suport leap seconds -- we should check and see what happens when you try to encode a 61st second. Probably:

ValueError: minute must be in 0..59

Which I think is correct behavior, but it would be good to make sure.

(and maybe add a more informative message???)