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>