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