[arch-general] timezones

[Jorge Almeida]

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

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

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).

>> 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.)

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.

>> 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...
>
Cheers

Jorge Almeida