Re: [PATCH] Add support for leap seconds in zoneinfo files

[Rich Felker <dalias@aerifal.cx>]

On Wed, Nov 27, 2013 at 04:10:35AM +0000, Laurent Bercot wrote:
> 
> >By the way, this brings me to one part of the proposed patch that I'd
> >definitely like to see changed: the pre-parsing the leapseconds data
> >and storage in static memory. This both wastes static storage (800
> >bytes for 64-bit systems) and puts an arbitrary limit on the data size
> >where it's not needed. I'd really prefer that the leapsecond
> >processing happen direct from the mmapped space, just like the way
> >time zone transitions are handled.
> 
>  Ok, but that will be more invasive. Time zone transitions can all be
> performed in __secs_to_zone, but leap second data needs to be available
> for __secs_to_tm and __tm_to_secs, since we only want to perform leap
> second calculations when converting from/to broken-down time, not when
> returning raw seconds: so interface changes will be necessary.

__secs_to_tm and __tm_to_secs are not the right places for applying
leap seconds, because they affect gmtime, which is specified strictly
by POSIX to have a particular relationship with time_t...

> >It would also be preferable to use
> >a binary search like what's used on the transition list instead of a
> >linear search; this change to binary search would probably more than
> >compensate for any performance loss from reading directly from the
> >mmapped data.
> 
>  I don't think it's needed. The leap second table is searched in
> descending order, and most calls to time functions are made with the
> current time, or something close to it, so a linear search will stop
> at the first item in most cases. And the rare worst case is only 25
> iterations for now. I'll change to binary search if you insist, but
> I really feel it would add complexity for a very tiny benefit in the
> rare case and no performance increase at all in the common case.

I'm faily indifferent on it, but I don't think the binary search is
significantly more complicated.

Rich