From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4372 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: Thu, 05 Dec 2013 16:31:38 +0000 Message-ID: <52A0AA6A.60608@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> 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 1386261109 6671 80.91.229.3 (5 Dec 2013 16:31:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 5 Dec 2013 16:31:49 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4376-gllmg-musl=m.gmane.org@lists.openwall.com Thu Dec 05 17:31:54 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 1VobqB-0007el-C2 for gllmg-musl@plane.gmane.org; Thu, 05 Dec 2013 17:31:51 +0100 Original-Received: (qmail 16042 invoked by uid 550); 5 Dec 2013 16:31:50 -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 16034 invoked from network); 5 Dec 2013 16:31:50 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=LKe0upriuPJkJqO07lrRdtxc8AlQ5C1jNxcTed6Gc+0=; b=iUm349i1cpeA+EDXzzdDtAyWVHeIt6PIxEs2E2sw2xvz7Ll8alF/Zo34OItEg9KHCr ScltLKhQt4MnWq8bu6xwrGHg71oIUhkELRMT5WHtNKUUYeZNn+7W9JKSyqEiqrVzxcyY hZqP2eBti6wvrxBMbOVebgQuATvi6clEJIoX5WTv5n/SyH7FeTARUYaob8jKMkej2FrN Oyjmhp1qmz120hp69fcFpWnrM6q10M2tv0XpJ2mDIxp2J2/DZkoD7ZQPEOeVXgLhbNid 8OunjEaQrbyDsNUPwdVZws/zmry/RQzHAB3bZ3/90KROZVLHFayK+MJpNL8Zwug40Qlb rC+w== X-Received: by 10.204.202.196 with SMTP id ff4mr1705630bkb.6.1386261098995; Thu, 05 Dec 2013 08:31:38 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 In-Reply-To: <20131205144311.GG24286@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:4372 Archived-At: Eh, that's fine. I have workarounds for libcs that don't support leap seconds. As long as that support is going to make it into musl *eventually*, I'm not disappointed. So, let's discuss. > - gmtime depends on the TZ variable Yes. Functions that display human time need to derive it from the system time, so they need to know what the system time is. POSIX sidesteps the problem by saying "the system time will be aligned with some human time (UTC)"; but if you do not want the system time to be aligned with UTC, then you have to make those functions aware of what the system time is. gmtime() cannot be the same function when your system time is UTC and when it is TAI-10: it needs to be given that information. Since zoneinfo files include that very information - the leap second table - then I figured it made sense to use them: the timezone tells gmtime() how to interpret the system time. Timezones are used not only as a UTC <--> local time information provider, but also as a UTC <--> system clock time information provider. Note that TZ values pointing to POSIX timezone definitions will never change gmtime()'s behaviour. I am not fundamentally opposed to conveying the information in another way, as long as it can be done consistently. > - gmtime behaves unpredictably depending on whether a function that > loads the timezone has or has not been called prior to calling > gmtime. This is indeed a bug - an oversight on my part, sorry. Would calling do_tzset() at the beginning of gmtime_r() fix it ? Would it be prohibitively expensive, and if so, what would be a better solution ? > - there's no synchronization in gmtime's (or gmtime_r's) access to the > leap seconds data so the latter isn't even thread-safe. OK, if changing timezones during the lifetime of a process is a valid use case, then things must be protected. There needs to be a read-only lock around __leapsecs_add() and __leapsecs_sub(), and a read-write lock around the setting of __leapsecs_num and abbrevs_end. I couldn't find such a thing as a shared lock system in musl, though. Should I go for LOCK and UNLOCK, even though it would uselessly prevent concurrent reads, or is there a better way ? > What I can tell you is that this code (the time internals) is not > something I expect to make any changes to between now and some time > after 1.0, so for your own usage or usage by anybody else who wants > it, your patch should continue to apply successfully. I intend to maintain it until it gets integrated. > And I don't mind > further discussion of how to improve it in the mean time, but in the > immediate future my focus on musl will be getting 0.9.15 and 1.0.0 > releases ready according to the existing plan, without big invasive > changes. Please consider integrating it for 1.0.0 if it meets all your criteria by then. -- Laurent