[tz] posix timestamp compatibility library for systems using right timestamp

Zefram zefram at fysh.org
Wed Feb 12 11:13:58 UTC 2014

Marek Behun wrote:
>I have written a small POSIX timestamp compatibility library for
>glibc/linux systems which use right timestamp on system clock (and also
>a 'right/' timezone).
>By executing a program with LD_PRELOAD=/path/to/time2posix.so

This is interesting and valid, but scarily fragile.  It's something of a
problem that time_t in general has these two interpretations (the POSIX
interpretation and the one implied by the `right' tz files).  At present
the problem is minimised firstly by the inherent segregation between
`posix' hosts and `right' hosts, and secondly by the sheer rarity of the
latter.  Your library does away with the per-host segregation, so that now
different time_t slots on a single host have different interpretations.

This *can* be done correctly, but having your modified time() et
al masquerade as the ordinary libc functions makes it as difficult
as possible.  As a single program can be run against either version of
the functions, there's no explicit indicator of which flavour of time_t
is being used, and it's not immediately obvious when there's a mismatch,
you're bound to get them mixed up sometimes.  Anyone who uses the preload
has to be aware of this, and to track very carefully where time_t is used
(in data files, where it's not necessarily documented) and which flavour
of it is used in each place.

>                                    when using for example ntpdate
>to synchronize from such a server, ntpdate doesn't have to be patched
>to synchronize to right timestamp (instead of posix).

Interesting, that's pretty much the reverse of the use cases I first
imagined.  (I was thinking of user-oriented programs getting the preload,
where they embed too much knowledge of the POSIX version of time_t to
function correctly on a `right' system.)  Whichever programs it's used
on, minimising the number of them helps in keeping the two versions of
time_t separate.  The worst possible arrangement would be to apply the
preload to the majority of programs.

>I would like to know if I should continue developing this library

I can't give a good answer about the prevalence of the `right' system.
I think your library is a useful aid for people who do run such systems,
or who would like to but are currently put off by the incompatibilities
it would suffer.

I see that you only read the leap second table once, at startup.
This will go wrong for long-running programs such as ntpd.  You should
periodically check for newly-announced leap seconds by rereading the
LEAP_TZFILE.  The trigger condition for this should be something like
the time_t that you're converting being over a month later than the time
was when you last read the file.


More information about the tz mailing list