Date: Fri, 06 Dec 2013 00:36:29 +0000 From: Laurent Bercot <ska-dietlibc@...rnet.org> To: musl@...ts.openwall.com Subject: Re: [PATCHv2] Add support for leap seconds in zoneinfo files > 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
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.