From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4374 Path: news.gmane.org!not-for-mail From: Laurent Bercot Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCHv2] Add support for leap seconds in zoneinfo files Date: Fri, 06 Dec 2013 00:36:29 +0000 Message-ID: <52A11C0D.1080705@skarnet.org> References: <5294EE35.8040603@skarnet.org> <20131126233212.GE24286@brightrain.aerifal.cx> <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> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1386290173 22605 80.91.229.3 (6 Dec 2013 00:36:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 6 Dec 2013 00:36:13 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4378-gllmg-musl=m.gmane.org@lists.openwall.com Fri Dec 06 01:36:19 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 1VojP1-00059X-7G for gllmg-musl@plane.gmane.org; Fri, 06 Dec 2013 01:36:19 +0100 Original-Received: (qmail 9727 invoked by uid 550); 6 Dec 2013 00:36:18 -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 9718 invoked from network); 6 Dec 2013 00:36:18 -0000 X-SourceIP: 89.100.252.69 User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 In-Reply-To: <20131205164022.GK24286@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:4374 Archived-At: > 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(), 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. > 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. > [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. Strictly POSIX systems wouldn't be impacted at all anyway. -- Laurent