* Steve Langasek <[EMAIL PROTECTED]> [2006-08-23 01:14]: > > 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? > > Nope. > > > Would it be better to write a simple, one-purpose, C program to do what > > you want? > > Yes, C is the implementation language of choice here. I think the ideal > solution would be to add an "output offset" feature to whatever rdate client > is used in d-i.
waldi, do you know if that would be acceptable for busybox's rdate. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
