[tex-live] tlmgr

[Zdenek Wagner]

2012/11/2 Reinhard Kotucha <reinhard.kotucha at web.de>:
> On 2012-11-01 at 23:14:49 +0900, Norbert Preining wrote:
>
>  > Indeed. I assume now that the time call used by perl links to the
>  > syscall and that is depending on the current summer/normal time
>  > settings.
>
> Hi Norbert,
> there is no black magic and as far as I can deduce from the code,
> neither the installer nor tlmgr have problems with DST/standard time
> transitions.
>
> Unix uses UTC internally throughout the system.  Conversion to local
> time takes place when times are displayed to users.  And only there
> it make sense.  Example:
>
>   $ touch foo
>
>   $ ls -l foo
>   -rw-r--r-- 1 reinhard users 0 Nov  2 22:23 foo
>
>   $ TZ=/usr/share/zoneinfo/Asia/Tokyo ls -l foo
>   -rw-r--r-- 1 reinhard users 0 Nov  3 06:23 foo
>
> The time stamp in the inode is in UTC, the conversion to local time is
> done by ls (and system libraries).
>
> The function TLUtils::time_estimate() is using the built-in function
> time(), which returns the number of seconds since 1970-01-01 00:00 UTC.
> This function always yields correct results because it depends on UTC
> entirely...
>
> ...except, of course, if an ntp client changes the system time while
> tlmgr is running, as in Herbert's case.
>
> As far as I can see,  the installer and tlmgr are using Perl's
> localtime() function only in order to insert human readable time
> stamps into log files, which is safe and desired.
>
> In order to avoid sudden clock changes, I can only second Zdeněk's
> proposal: Run /sbin/hwclock --systohc from time to time.
>
It depends... When Linux boots, the time is taken from the HW clock.
During boot the network starts, then chrony starts and tries to find
ntp servers. You can use their domain names, not just IP addresses
because bind starts before chrony. Depending on many factors
synchronization may occur within a few seconds but may take more than
half an hour. If the shift is less than 15 minutes, the hw clock is
set by the kernel thus upon the next boot the time will be almost
correct. However, if the shift is greater than 15 minutes, the hw
clock will not be modified. It that has two consequences:

1. The time is wrong after each boot

2. When the ntp servers are contacted for the first time, the time
jumps immediatelly

If you install a newly bought computer, the hw clock is usually wrong,
depending on what the manufacturer did with the motherboard. The
difference may even be several years. This s why you have to update
the hw clock manually (if chrony tells you that it is already
synchonized). If the computer runs regularly and ntp servers are
accesible, the difference will not be greater than 15 minutes, Linux
will use information from the driftfile and the kernel will update the
hw clock automatically.

But this is not the whole truth. You have two options how to handle
the hw clock. If the computer is a single boot Linuch machine, it is
better to run the hw clock in UTC. In such a case you will have no
problems. If you use dual boot and switch between Linux and Windows or
eComStation, you must run the hw clock in the local time. And then you
have problems with the daylight saving. Twice a year the time will be
shifted one hour which is more than 15 minutes and thus the hw clock
will not be set by the kernel.

As Reinhard wrote, the Linux kernel clock runs in UTC. If your hw
clock runs in UTC too, the kernel just takes the value upon boot. If
the hw clock runs at the local time, the kernel must apply the TZ
information in order to to set the UTC time from the hw clock running
at local time. In such a case you have to set the hw clock manually
twice a year.

/var/log/messages tells you what happens upon boot. If you see a
sudden jump in time when chrony starts and notes that the time was
set, you know that setting the hw clock is needed.

> Regards,
>   Reinhard
>
> --
> ----------------------------------------------------------------------------
> Reinhard Kotucha                                      Phone: +49-511-3373112
> Marschnerstr. 25
> D-30167 Hannover                              mailto:reinhard.kotucha at web.de
> ----------------------------------------------------------------------------
> Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
> ----------------------------------------------------------------------------
>



-- 
Zdeněk Wagner
http://hroch486.icpf.cas.cz/wagner/
http://icebearsoft.euweb.cz