Re: localtime()

> but gave up using right/ timezones under GNU/Linux,
> mostly because patches to eg. OpenNTPD are required
> (OTOH now I???m a DD I could do that???).

 Yes, the main problem with the TAI-10 setup is ntpd. The problem
with ntpd is twofold:
 * the NTP protocol exports UTC only (and even worse, but let's not
delve into that) ;
 * the ntpd daemon insists on setting the system clock itself (and
it assumes the system clock should be on UTC) instead of just
computing time offsets and letting another program set the clock,
as a well-designed program should do.

 TAI-10 can only be used on a system where ntpd does not run; but
you can still use a NTP client such as DJB's sntpclock, which exports
the time offset to the clockadd program, to sync your clock. You just
have to substract leap seconds before setting the system clock.


> Calling a seconds-since-some-epoch value UTC is a
> misnomer IMO, as UTC is a wallclock ???unit???.

 http://www.madore.org/~david/computers/unix-leap-seconds.html#the-spec
 When I'm using "TAI" and "UTC", this page explains clearly and
unambiguously what these terms mean.
 "n seconds UTC" means "n linear seconds since 1970-01-01T00:00:10 TAI
plus leap seconds", i.e. the number of seconds that represents the
correct wallclock UTC time when broken down using the POSIX formula.


> But yes, with right/ timezones, the kernel time must count
> leap seconds, and things like OpenNTPD/rdate need to know it.

 "kernel time" does not have to count leap seconds: it can be done at
the application level. That's why I prefer the term "system clock".
 My skalibs library, which is originally inspired by DJB's work,
includes flags to check what setting your system clock is set to:
 http://www.skarnet.org/software/skalibs/flags.html#clockistai

 Unfortunately, as you say, programs such as ntpd and rdate are not
that flexible and assume the system clock is set to UTC, which is not
always the case, and they need to be patched if used on a TAI-10 setup.


> (Also, please avoid writing TAI because of the possible confusion
> with DJB???s tai64_t which has a bias of 2³???.)

 There is no possible confusion: TAI is TAI. DJB uses TAI in the exact
same way that I do. The TAI64, TAI64N and TAI64NA external formats, as
well as the "struct tai" and "struct taia" data types, are meant to
represent and store TAI values (and sometimes they don't, but that is a
whole other question).
 The "TAI-10" setup means that the system clock represents TAI minus
10 seconds, i.e. that the Epoch is 1970-01-01T00:00:10 TAI and time has
been counted linearly, with a constant second duration, since that Epoch.
DJB uses this very setup and so do I. It's not confusion when we mean
the same thing ;)

-- 
 Laurent