[LEAPSECS] Proposal regarding tz DB and leap second updates

[Ian Batten]

On 14 Aug 2013, at 03:44, Warner Losh <imp at bsdimp.com> wrote:


> 

> On Aug 12, 2013, at 10:59 AM, Steve Allen wrote:

>> On Mon 2013-08-12T18:44:39 +0200, Martin Burnicki hath writ:

>>> My proposal is to use some sort of network protocol to deploy the

>>> contents of the tz DB, either for a single time zone used on a

>>> system, or even for all time zones supported by the tz database.

>> 

>> See the efforts of

>> http://calconnect.org/tc-timezone.shtml

>> 

>> Be aware that they are working in a framework which does not share all

>> the vocabulary of the IANA tz community efforts and that their draft

>> does not currently transport the information found in the tz

>> "leapseconds" file.

> 

> How does this proposal address the long running program issues (consider a demon that runs for many years that needs to produce proper UTC time stamps when the underlying system is running some variation of TAI)? How does it do the updates without affecting the performance of all time calls? Last I checked the time code doesn't check to see if there's new timezone info before doing the output, which means very long running demons have to cope with this somehow...


It's a very narrow use-case to talk about printing (or whatever) just UTC.  Most daemons that have timestamps on log entries potentially also respect both local time and daylight savings time, and the rules for the relationship between those and UTC are subject to change with little warning, certainly less than the notice period for leap seconds.   So if it's the case that localtime() and friends don't check for changes in the underlying TZ data then the issue of long-running daemons is already a live one.

ian