Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 27 Nov 2013 05:53:28 +0000
From: Laurent Bercot <>
Subject: Re: [PATCH] Add support for leap seconds in zoneinfo files

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

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.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.