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
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
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
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
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
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
participants (3)
-
Jorge Almeida
-
Mauro Santos
-
Tom Gundersen