Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!apple!snorkelwacker!bloom-beacon!ais1.bal.mmc.COM!wicks From: wicks@ais1.bal.mmc.COM (Anthony B. Wicks) Newsgroups: comp.windows.x Subject: xclock Message-ID: <9006291354.AA03725@ais1.bal.mmc.com> Date: 29 Jun 90 13:54:39 GMT References: <9006281614.AA12765@lyre.MIT.EDU> Sender: daemon@athena.mit.edu (Mr Background) Organization: The Internet Lines: 40 Organization: DEC/MIT Project Athena Date: Thu, 28 Jun 90 12:14:30 EDT From: Ralph Swick > Has anyone at MIT considered changing xclock to accept another > argument, a time offset? A long time ago when our kernels were a few weeks out of sync wrt the change in the change in Eastern Standard Time to Daylight Savings Time (or vice-versa, I don't remember now), I hacked in a -offset flag, so the answer is "yes". The hack didn't stay. > Is it possible to update xclock to handle a different time zone > without updating Xaw? probably not. The Clock widget should be fixed to use a callback to get the time and the calls to time() and localtim() should be moved out of the widget into xclock.c in this callback. Now that you know how to do it, we'll expect a bug report with the correct fixes from you soon. :-) As a widget the clock widget would be less than a clock if it didn't kep time. I think time() and localtime() are fine where they are, but that the clock widget should have a timezone resource to handle the offset problem. I would also like to see/add a "face" resource which could be analog, digital, or both. On to of this I would create a composite widget (If I ever get the time) that would add features: let's have a useAlarm, an alarmTime, and an alarmMessage. --Tony __________________________________________________________ Staff Engineer, Martin Marietta Aero & Naval Systems, Software Department Local MMA&NS Email: wicks@mst1.bal -- 301-682-2883 (Desk) 301-682-0975 (Lab) INTERNET: wicks@mst1.bal.mmc.com -or- wicks@umbc3.umbc.edu