On Aug 19, 2006, at 2:52 PM, Steve Langasek wrote:
On Sat, Aug 19, 2006 at 04:47:44PM +0200, Frans Pop wrote:We mainly need to determine how we are going to use rdate: - for all installations; - only for some (sub)arches like nlsu; - only if difference between system date/time and rdate date/time is greater than x.Seems to me there needs to be a link with clock-setup as I guess rdate would set the time to UTC. So either clock-setup would need to reset theclock if "local time" is selected, or it would have to default to UTC too. We could even use rdate to guess if clock is set to local time or UTC based on the difference between system time and rdate.For countries with more than 1 timezone, I want to be able to set a default timezone for the system based on the offset between the system clock and theremote timeserver as well... :)
RFC 868 (http://www.rfc-archive.org/getrfc.php?rfc=868) says that the rdate protocol delivers time as a 32-bit binary integer in units of seconds since midnight on January first 1900 GMT (time 1 is 12:00:01 am on 1 January 1900 GMT).
The rdate command prints time in the prevailing timezone (as specified by the TZ environment variable, to to print the date and time in UTC, do "TZ=UTC rdate -p").
There is no option for the rdate command to print anything but a formated date/time. This means that the output will have to be parsed back into a binary integer before you do the calculations needed to deduce the time zone. This is, of course, possible. But shell script wouldn't be my language of choice for doing it. Regardless of the language, getting the fiddlly bits just right (leap years leap seconds) just right is tricky business. It's best to use a pre-existing library to do the hard part.
Do you have access to perl or python at the time you want to do this? Do you have access to the date/time libraries for either of those languages? Would it be better to write a simple, one-purpose, C program to do what you want?
Rick