In article <3FA2AB58.firstname.lastname@example.org>,
Phil Brady <email@example.com> wrote:
> Am I right in thinking that an NTP service will only deliver UTC (in
> secs since 1/1/1900) and no other time information? Hence the other
Technically it excludes leap seconds.
> bits of the jigsaw to compute local time ie the offset from GMT (+1 hour
> for Paris etc) and any daylight saving adjustments are a local
> responsibility of the client without any hints given by NTP ?
These are attributes of the user, certainly not the NTP client and,
in reality, not even the client interpreted as the whole machine. Some
operating systems designed/licensed for single user, desk top use, may
confuse the distinction between the operating system and the user
interface, and derivatives of them may even further confuse the
issue by storing the wall clock time in CMOS, even though properly
correcting internally for multiple users.
However, for as long as I've known Unix, the final selection of timezone
information has been per-process, inheriting towards the leaves of the
process creation tree, unless overridden at a specific node. If one
sets the zone at the process nodes corresponding to each user's top
level command interpreter, each user has all their processes operating
in their own timezone (or at least their choice of it when they started
the process). There is often some way of providing a global default;
in very early ones, the kernel knew the timezone and in the best current
system, there is a file that defines the default, but these can always
be overridden locally.
When I first used Unix, one could only override the timezone in one hour
steps and the daylight saving time changes only allowed for the, then,
US rules. More recent ones allow minutes and allow the daylight saving
time changes for the current year to be encoded (normally as month and week
number, with week 5 meaning the last week).
The best current system, as used on typical Linux distributions, has
files with the historic rules for each timezone and any known future
projections. This makes it much easier to cope with changing legislation
(a few years ago, the UK re-enacted secondary legislation each year to
override the times of the changes from those in the primary legislation;
currently this, secondary, legislation specifies the same rules as the
rest of western Europe). It also means that the system can correctly report
historic file modification times in whatever timezone the user chooses.
The main issue left over is whether to include or exclude leap seconds in
the internal form of the time. Posix specifies, like NTP, that they be
excluded, and this makes forward calculation of times for civil and deep
space astronomical purposes possible and backwards calculations easy.
Some purists prefer to have the leap seconds included, so that there are
no doubled up or missing seconds and other classes of time interval work
correctly with simple arithmetic on the times (calculating planetary
positions requires such calculations, but exactly where to point the
telescope also involves the other).