[arch-general] timezones

[Mauro Santos]

On 09-11-2011 09:22, Jorge Almeida wrote:
> On Tue, Nov 8, 2011 at 10:07 PM, Mauro Santos
> <registo.mailling at gmail.com> wrote:
>> On 08-11-2011 18:20, Jorge Almeida wrote:
>>> I have
>>> HARDWARECLOCK="UTC"
>>> TIMEZONE="right/Portugal"
>>
>> Here I use Europe/Lisbon as timezone, I guess one should use a valid
>> timezone as found in /usr/share/zoneinfo
>>
> 
> I don't understand what you mean by "valid" (the same for Tom's reply):
> 
> $ file /usr/share/zoneinfo/right/Portugal
> /usr/share/zoneinfo/right/Portugal: timezone data, version 2, 11 gmt
> time flags, 11 std time flags, 24 leap seconds, 221 transition times,
> 11 abbreviation chars
> 

You are correct, right/Portugal does indeed exist :)

> I've been using this for a long time (on Arch, and previously on
> Gentoo). My problem is just that I don't understand the big picture. But
> I think I'm guessing it (after my original post).
> 
> $ date; TZ="Portugal" date
> Wed Nov  9 08:27:04 WET 2011
> Wed Nov  9 08:27:28 WET 2011
> 

For me using:
HARDWARECLOCK="UTC"
TIMEZONE="Europe/Lisbon"
The output is the same.

> So, "date" with the set timezone ("right/Portugal") has 24s less than with
> "Portugal" (the latter, BTW, is identical to "Europe/Lisbon"). This seems the
> right thing (24 leap seconds make the UTC time appear late, but it is the
> official time, as far as I understood).
> 

Maybe I misunderstood you at first, do you want date to return the
International Atomic Time (TAI) or the Coordinated Universal Time (UTC)
which will always be within +-1 mean solar time (UT1) which is also
considered the legal time?
If you want it to return TAI then 24s does not seem to be the correct
difference[1]. Or maybe it is since time in *nix starts from 1970.

>>> in /etc/rc.conf, but I'm not sure this is the right thing to do. I use
>>> clockspeed to keep the clock synchronized with a ntp server, and other
>>
>> From the small description on the download(?) page [1] of clockspeed the
>> objective of the program is to try and keep the time accurate when there
>> is no network connectivity, but you say you synchronize with a ntp
>> server. ntpd[2] also keeps a drift file to account for clock drift and
>> ntpd is widely used and well maintained.
>>
> clockspeed keeps the clock right (to the tenth of second, at least) by checking
> the hw clock every 3secs and by making tiny-tiny adjustments if needed. It
> decides whether it is needed based on information about the hw clock behavior
> that is kept is a binary file. This file is fed by sporadic connections to a
> ntp server, so the computer doesn't have to be always connected to the net. (By
> experience: a box always on but without net connection will have accurate time
> for months. If you turn the box off at night, it will drift a few secs.)
> 

With ntpd I have never seen the clock in my laptop out of sync by more
that +-1s (if turning the laptop off at night) when checking here[2],
but I have to say I have internet connectivity every day (thus ntpd can
sync) and it's not something I check very often because a few seconds of
time difference don't matter to me. If I leave the laptop on, ntpd will
slowly adjust it to within +-0.02s according to[2].

> clockspeed is not maintained at all, but it doesn't need to, it works as it is
> (and no one found a bug in it). But one might appreciate less terse
> documentation, indeed.
> 

The problem about not being maintained is that it can break at any time.
The other catch is that if you are not using something that more people
use it will be quite hard to get help if you have any problems.

>>> sofware requires a "right/*" timezone. Anyone has any knowledge to share
>>> about this issue?  For example, "date" gives output that ignores leap
>>> seconds. Is this a date issue, unrelated with rc.conf? Anyone else using
>>> a right/* timezone?
>>
>> I'd say leap seconds are a time reference problem, date only reports
>> what the time reference says. If you continually sync with a ntp server
> 
> Yes, I think I was wrong assuming that date was giving the wrong time. date
> takes leap seconds into account if the timezone knows about it (which it does,
> it it is right/*).
> 
>> then leap seconds will be taken care of when ntpd syncs, I'd say that if
>> you need such an accurate time reference that leap seconds matter then
>> maybe using a pc and the normal timekeeping methods is not the best choice.
> 
> No, you can keep accurate time with cheap hw. I have a 3GHz P4 on a cheap mo,
> and:
> 
> $ clockdiff
> before: 2011-11-09 08:53:26.038448000000000000
> after:  2011-11-09 08:53:25.954360501330338418
> 
> (Never mind the name of the command, which is not standard). The
> "before" is the current time in the computer, "after" is the time in a
> ntp server; they would be equal if the computer was absolutelly
> synchronized with the server)
> 
> I think my mistake was to assume that this time takes leap seconds into
> account. It seems it doesn't, and it's up to the software to correct it. It
> seems that gettimeofday() doesn't, either, which was what puzzled me...

I guess I shouldn't try to puzzle you more ... as this was something I
have never looked at that much as it just worked but apparently
timekeeping is not as simple as it seems.


[1] http://en.wikipedia.org/wiki/International_Atomic_Time
[2] http://www.oal.ul.pt/index.php?link=acerto#

-- 
Mauro Santos