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