From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4377 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCHv2] Add support for leap seconds in zoneinfo files Date: Fri, 6 Dec 2013 06:31:46 +0100 Message-ID: <20131206053146.GC1685@port70.net> References: <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> <20131206004535.GT24286@brightrain.aerifal.cx> <52A12548.80508@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 1386307914 458 80.91.229.3 (6 Dec 2013 05:31:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 6 Dec 2013 05:31:54 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4381-gllmg-musl=m.gmane.org@lists.openwall.com Fri Dec 06 06:32:00 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 1Voo1A-0004t0-I8 for gllmg-musl@plane.gmane.org; Fri, 06 Dec 2013 06:32:00 +0100 Original-Received: (qmail 3967 invoked by uid 550); 6 Dec 2013 05:31:58 -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 3954 invoked from network); 6 Dec 2013 05:31:58 -0000 Content-Disposition: inline In-Reply-To: <52A12548.80508@skarnet.org> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4377 Archived-At: * Laurent Bercot [2013-12-06 01:15:52 +0000]: > >At the very least they would have some overhead determining that > >leapseconds aren't in use. > > Indeed, one test at executable start. :) > Do you have any idea what form this test would take, if we're opting > away from TZ ? - musl should not have configuration options that change the behaviour of an api (otherwise maintaining the code becomes much harder) so making leapseconds a libc build time config option does not work - hardcoding leapsecond tables into libc does not work either requires recompilations and restarts - if the clock source is a kernel level setting then the information should come from the kernel (eg in the aux vector or /proc) - if the clock source setting is an external setting (eg the configured time server uses GPS or TAI time scale) then the admin should provide the information through the filesystem, but an update is still an operational hazard, and we need to invent a file format and provide tools to get it from the distributed tzdata files - during the life-time of a process adding leapseconds may cause problems so the data should be cached at startup or on demand at the first gmtime call, but then there might be problems across processes if they don't have the same cached leapsecond list (the 86401 second day can cause problems no matter how we do this: communicating unix time across systems with different time scale or inserting future dates into databases based on unix time when the leap seconds are not yet known, etc)