unexpected leap second behaviour

[stephane-chazelas]

README.md has:

If supported by the system's zoneinfo database leap-second adjusted
calculations are possible. Use the unit rs to denote "real" seconds:

$ dateadd '2012-06-30 23:59:30' +30rs
=>
  2012-06-30T23:59:60

And indeed:

$ dateadd '2012-06-30 23:59:30' +30rs
2012-06-30T23:59:60

Or:

$ dateadd '2012-06-30 23:59:59' +3rs
2012-07-01T00:00:01

But trying for other leap seconds:

$ dateadd '2005-12-31 23:59:59' +3rs
2006-01-01T00:00:02

Doesn't seem to account for any leap second:

$ dateadd '2008-12-31 23:59:59' +3rs
2009-01-01T00:00:00
$ dateadd '2008-12-31 23:59:59' +2rs
2008-12-31T23:59:61

Seems to introduce 2 leap seconds on that day.

That's with both dateadd from dateutils 0.4.11-2 package on Debian, and the one built from current git head:

$ git describe
v0.4.11-37-g50855087

I'm not sure what system's zoneinfo database leap-second refers to, but in my case, strace shows dateadd doesn't open any zoneinfo file (nor /etc/localtime if $TZ is unset).

[hroptatyr]

Hi Stephane, very good catch. A fix is in c510bff.

I tried backtracking when this issue first occurred, and it seems it had never been working. So a big fat thank you to you.

Also, I addressed the confusing statement in the README.md. You're right indeed that dateutils would not access the system's zoneinfo files for leap second adjustments. For the moment the list of transitions is built-in.

It's still an idea (of the maybe-one-day kind) to confer the system for up-to-date transitions. Not sure if the effort is worth it though.

[stephane-chazelas]

Hi Stephane, very good catch. A fix is in c510bff.
[...]
It's still an idea (of the maybe-one-day kind) to confer the system for up-to-date transitions. Not sure if the effort is worth it though.

Thanks for the fix.

https://en.wikipedia.org/wiki/Leap_second#Long-term_outlook suggests there likely won't be new leap seconds in a while, so may not be worth the effort.