Date: Tue, 12 Oct 1999 18:45:28 -0400 (EDT) From: "Crist J. Clark" <cjc@cc942873-a.ewndsr1.nj.home.com> To: dread@texas.net (Don Read) Cc: sheldonh@uunet.co.za (Sheldon Hearn), freebsd-questions@FreeBSD.ORG, cjclark@home.com Subject: Re: XClock UTC? Message-ID: <199910122245.SAA35321@cc942873-a.ewndsr1.nj.home.com> In-Reply-To: <XFMail.991012141609.dread@texas.net> from Don Read at "Oct 12, 1999 02:16:09 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Don Read wrote, > > On 12-Oct-99 Sheldon Hearn wrote: > > > > > > On Tue, 12 Oct 1999 14:22:59 +0200, Sheldon Hearn wrote: > > > >> No. From the xclock manpage: > > > > Damn, I made a mistake when checking for existing follow-ups to your > > question, otherwise I wouldn't have embarrassed myself like this. > > > > Anyone know when xclock started grokking TZ? > > > > My understanding is libc.[a/so] handled localtime conversions. Since, surprisingly, people do seem to have a non-negligible interest in the question, I'll pass along what I had found. I did have a look at the source code later on yesterday when I had the time. xclock(1) does the following (from XClock.c), (void) time(&time_value); tm = *localtime(&time_value); str = asctime(&tm); And no further processing of the text string is done. As for how TZ gets involved in there, see localtime(3). It seems like it would be only slightly more than trival to change that asctime(3) call into a strftime(3)[0] call and add the needed command line/environmental/Xdefaults to get a format string used. Maybe if I get really bored this week... [0] Love the bug note on strftime(3), "BUGS There is no conversion specification for the phase of the moon." -- Crist J. Clark cjclark@home.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910122245.SAA35321>