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

[Laurent Bercot <ska-dietlibc@skarnet.org>]

> __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...

  I disagree that they are not the right place for it.

  * the point of using TAI-10 instead of UTC is to have a linear system
clock, so leap seconds must not be applied to clock_gettime() and
friends.

http://pubs.opengroup.org/onlinepubs/9699919799/functions/time.html and
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_15
are vague enough ("approximate the number of seconds that have elapsed since
the Epoch") for TAI-10 to be a compliant setup here. The numerical relationship
between number of seconds and broken-down time is not respected if there are
leap seconds, but:

  * http://pubs.opengroup.org/onlinepubs/9699919799/functions/gmtime.html
makes it very clear that gmtime() should return UTC, and user applications
like "date" rely on it, so if there are leap seconds, they should definitely
be applied here;

  * POSIX followers will use posix/ timezones with 0 leap seconds anyway,
so the numerical relationship will be respected.

  To sum it up:
  - leap seconds break POSIX anyway, but should break as little as possible
  - leap second users only care about system clock time, not broken-down time
  - so gmtime() should always return UTC, this is relied on by userland so
it's more important than the exact relationship between tm and secs
  - so time() should ignore leap seconds but broken-down time should apply them
  - so the right place to apply them is in __secs_to_tm and __tm_to_secs, the
conversion routines
  - using a posix/ zone will make everything POSIX in any case.

-- 
Laurent