From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4375 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCHv2] Add support for leap seconds in zoneinfo files Date: Thu, 5 Dec 2013 19:45:35 -0500 Message-ID: <20131206004535.GT24286@brightrain.aerifal.cx> References: <529570BB.2060804@skarnet.org> <20131127042550.GI24286@brightrain.aerifal.cx> <529588D8.3020006@skarnet.org> <20131127184307.GN1685@port70.net> <52965735.9070409@skarnet.org> <529FD33A.8000509@skarnet.org> <20131205144311.GG24286@brightrain.aerifal.cx> <52A0AA6A.60608@skarnet.org> <20131205164022.GK24286@brightrain.aerifal.cx> <52A11C0D.1080705@skarnet.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1386290742 28651 80.91.229.3 (6 Dec 2013 00:45:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 6 Dec 2013 00:45:42 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4379-gllmg-musl=m.gmane.org@lists.openwall.com Fri Dec 06 01:45:48 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1VojYC-0002AP-EV for gllmg-musl@plane.gmane.org; Fri, 06 Dec 2013 01:45:48 +0100 Original-Received: (qmail 15715 invoked by uid 550); 6 Dec 2013 00:45:47 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 15707 invoked from network); 6 Dec 2013 00:45:47 -0000 Content-Disposition: inline In-Reply-To: <52A11C0D.1080705@skarnet.org> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4375 Archived-At: 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