FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 11-08-2011, 05:20 PM
Jorge Almeida
 
Default timezones

I have
HARDWARECLOCK="UTC"
TIMEZONE="right/Portugal"
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
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?

TIA

J.Almeida
 
Old 11-08-2011, 09:07 PM
Mauro Santos
 
Default timezones

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

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

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

[1] http://cr.yp.to/clockspeed.html
[2] https://wiki.archlinux.org/index.php/Network_Time_Protocol_daemon

--
Mauro Santos
 
Old 11-08-2011, 11:26 PM
Tom Gundersen
 
Default timezones

On Tue, Nov 8, 2011 at 7:20 PM, Jorge Almeida <jjalmeida@gmail.com> wrote:
> I have
> HARDWARECLOCK="UTC"
> TIMEZONE="right/Portugal"
> 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
> 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?

This will not work. You need to use a timezone whose zoneinfo file exists.

-t
 
Old 11-09-2011, 08:22 AM
Jorge Almeida
 
Default timezones

On Tue, Nov 8, 2011 at 10:07 PM, Mauro Santos
<registo.mailling@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
 
Old 11-09-2011, 11:21 AM
Mauro Santos
 
Default timezones

On 09-11-2011 09:22, Jorge Almeida wrote:
> On Tue, Nov 8, 2011 at 10:07 PM, Mauro Santos
> <registo.mailling@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
 
Old 11-09-2011, 01:05 PM
Jorge Almeida
 
Default timezones

On Wed, Nov 9, 2011 at 12:21 PM, Mauro Santos
<registo.mailling@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
 

Thread Tools




All times are GMT. The time now is 04:43 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org