[arch-general] timezones

[Jorge Almeida]

On Wed, Nov 9, 2011 at 12:21 PM, Mauro Santos
<registo.mailling at gmail.com> wrote:
> On 09-11-2011 09:22, Jorge Almeida wrote:
>>
>> $ 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.

You mean "the same as the last line above", right? That's because
"Europe/Lisbon" and "Portugal" are really the same.
>
>>
>
> 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?

I want the official, legal, time, which I believe is UTC.

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

It is currently (24 leap seconds). It is bound to change every 6 months.

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

I suppose ntpd works, but it is much more complex and it changes your
clock, which I find less than ideal. I prefer using the ntp server to
retrieve information and have other software (clockspeed) use that
information. Polling the server is made through another service. I
prefer to be in control, rather than trusting a complex protocol (which,
BTW, must have root privileges to change the clock).
Note that on boot (or whenever, for that matter) I can also sync the
clock with the server if I want to, the clockspeed package has a
command for that. But the protocol used for keeping the clock accurate
is not dependent on that.

>>
>
> The problem about not being maintained is that it can break at any time.

True in general, not appliable here. The author (whom I don't know
personally) has a history of writing bug-free, well designed, software.
It didn't fail me yet. (Documentation is another issue, of course...)
Moreover, I have this stuff statically compiled against dietlibc, so it
is immune to software updatings that can go sour.

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

True. But I can already manage it (my post was about the timezone stuff,
not really about clockspeed). (This site can help, in case someone is
interested in this stuff: http://thedjbway.b0llix.net/index.html)
>
>
> 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.
>
Right, but it doesn't have to be that difficult either. Like most linux
problems, documentation is the main issue.

J. Almeida