[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131206004535.GT24286@brightrain.aerifal.cx>
Date: Thu, 5 Dec 2013 19:45:35 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: [PATCHv2] Add support for leap seconds in zoneinfo files
On Fri, Dec 06, 2013 at 12:36:29AM +0000, Laurent Bercot wrote:
>
> >The problem is that gmtime is not permitted to do so. tzset has side
> >effects like making the globals timezone and daylight change, and
> >certain time functions are specified to behave as if they call it,
> >while others are not (and therefore can't).
>
> I don't see anything in POSIX that forbids gmtime() to call tzset(),
There's also nothing in POSIX that says calling memset can't close all
open files. The reason it can't happen is the lack of any text
allowing it to happen. Functions in the standard cannot have any side
effects visible to a conforming application aside from those they're
specified or otherwise explicitly allowed to have.
A better example might be fgets. Some people have argued that by
giving fgets a pointer to a buffer, you're giving it permission to
write to any part of the buffer. This is not the case. fgets is
specified to behave as if by repeated calls to fgetc, and therefore it
cannot write to any position in the buffer except for the positions it
would write as if implemented by repeat calls to fgetc and sequential
storage.
> but if you're referring to the case where a user calls gmtime() and
> expects the "daylight" variable to remain unchanged, then yes, I agree
> that it is a problem.
Exactly. I'm referring to visible side effects.
> >The only way I see around
> >this is fairly invasive: possibly keeping around two timezones. Or
> >(almost equivalent) keeping timezone and leapseconds profiles
> >completely separate.
>
> I'm all for keeping timezone information (which is about conversions
> between UTC and local time) separate from leap second information (which
> is about conversions between system time and UTC).
> The tzdata package actually provides the leap second table as a separate
> file, and it was pretty bad design to include it into the zoneinfo binary
> files in the end.
> I have two suggestions:
> 1. Keep using the leap second information provided in the timezone
> files, but have a __leapsecs_init() function used by tzset, gmtime and
> friends, that only initializes __leapsecs_num and abbrevs_end, without
> other visible side effects. It requires mapping the file, so adding a
> flag to know whether tzset() has been called or not. It still makes gmtime
> depend on TZ.
> or 2. Compile a separate leap second information binary file along with
> the libc, and have a system-wide switch telling musl to use the leap second
> table or not. (And default to POSIX when the file does not exist, of
> course.) This is the approach I'm using with skalibs, and it's working for
> me, but the requirements for a libc may be different.
These approaches sound closer to something that might be acceptable.
Regarding the unfortunate coupling of timezone and leapsecond data
into a single file, do the zoneinfo files with leapseconds have their
timezone transition times stored in POSIX time or TAI?
> >[locking issues]
> >Note that the problematic aspects that are coming up are most
> >problematic because they're affecting not just users who want
> >leapseconds, but all users. If leapseconds affect gmtime and
> >leapseconds depend on TZ, all the sudden these issues apply to all
> >calls.
>
> This goes in favour of the "keep the leap second table in a separate
> file" design. We could drop the need for locking entirely, since a
> file can be atomically replaced, and new leap second announcements are
> rare enough that the policy could simply be to restart long-lived
> processes (to get the new mapping) when the file changes.
It seems really inconsistent to me that someone who's pedantic enough
to care about leap seconds wouldn't care about having to "reboot" (I
use this term loosely) their servers/daemons when a new one is
announced. If you're ok with that discontinuity what's wrong with just
losing the leap second?
> Strictly POSIX systems wouldn't be impacted at all anyway.
At the very least they would have some overhead determining that
leapseconds aren't in use.
Rich
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.
