news@mind.UUCP (The News Person) (04/06/88)
Using X10 on Sun 3's, xclock is now an hour behind, expecting daylight savings time to begin three weeks later than it has begun. The time returned by "date" or on an emacs mode line is correct. Does anyone know how we can fix xclock? From: ghh@confidence.Princeton.EDU (Gilbert Harman) Path: confidence!ghh Gil Harman Princeton University Cognitive Science Lab 221 Nassau Street, Princeton, NJ 08542 ghh@princeton.edu
swick@ATHENA.MIT.EDU (Ralph Swick) (06/28/90)
> 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. :-)
harkcom@potato.pa.Yokogawa.CO.JP (Alton Harkcom) (06/29/90)
Recently I tried to expand xclock to show the local time here and the local time at my home. I am new to widgets so needless to say I spent some time spinning my wheels. I found the widget in Clock.c and found that it uses time(2) and localtime(3). I tried to copy what I needed and add the ability to give a time offset. The attempt failed. After pulling out my hair (there wasn't much left to begin with) I decided it was still beyond me. Has anyone at MIT considered changing xclock to accept another argument, a time offset? If it has already been done, does it run under X11R3? Has anybody hacked out their own clocks which handle non-local time? Is it possible to update xclock to handle a different time zone without updating Xaw? Thanks in advance for any help offered. -- --harkcom@potato.pa.yokogawa.co.jp
wicks@ais1.bal.mmc.COM (Anthony B. Wicks) (06/29/90)
Organization: DEC/MIT Project Athena Date: Thu, 28 Jun 90 12:14:30 EDT From: Ralph Swick <swick@athena.mit.edu> > 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 ____________________________<Anthony B. Wicks, Jr>______________________________ 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
sundarv@hpclsv.HP.COM (Sundar Varadarajan) (06/29/90)
harkcom@potato.pa.Yokogawa.CO.JP (Alton Harkcom) writes: > Is it possible to update xclock to handle a different time zone > without updating Xaw? The Unix internal clock keeps time in terms of GMT and displays the local time based on the TZ environment variable. Look in /usr/lib/tztab to get the list of predefined TZ values. You can of course create your own. This is true for HP-UX which is SYSV based. For Eastern Standard time use env TZ=EST5EDT xclock For pacific time use env TZ=PST8PDT xclock This compensates for daylight savings as well. Sundar Varadarajan sundarv@hpda.hp.com
guy@auspex.auspex.com (Guy Harris) (06/30/90)
>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. If you're running a sufficiently modern version of UNIX (System III/V - although only later S5 versions can cope with DST outside the US; SunOS 4.0 and later; 4.3-tahoe and later; etc.), you don't need it - you just set the TZ environment variable for the process running "xclock", and off you go....
nick@bischeops.UUCP (Nick Bender) (07/01/90)
The following is an abbreviated README from a program called xchrono
which I posted to comp.sources.x not long ago. Pick it up at your local
archive...
File: xchrono/README
Xchrono is a multi-timezone, multi-face clock program for X Windows.
It has been tested on a Sun 3 and an HP9000s300.
STARTUP
-------
Several cities have been compiled into xchrono, and can be invoked with
command-line arguments, xchrono -help gives:
Usage: xchrono [-analog] [-bw <pixels>] [-digital]
[-fg <color>] [-bg <color>] [-hd <color>]
[-hl <color>] [-bd <color>]
[-fn <font_name>] [-help] [-padding <pixels>]
[-rv] [-update <seconds>] [-display displayname]
[-geometry geom]
[-width clockWidth] [-height clockHeight]
[-dayFirst] [-local localName]
[-boston] [-newyork] [-chicago] [-denver] [-la]
[-hawaii] [-tokyo] [-sydney] [-london]
[-paris] [-frankfurt] [-rio]
OK, OK, Hawaii isn't a city, but you get the point. The timezones used
are taken from tztab in the SYSV case, and from /usr/lib/zoneinfo
otherwise, and as such may or may not be correct (the TZ variable
definitions or the city->timezone mappings). The AM/PM string in the lower
left corner will have an asterisk ("AM*") if the timezone is currently
under daylight savings time. The date string in the lower right is by
default in month/day format, but can be switched by the -dayFirst flag.
The -local <localName> option causes a clock labeled with <localName>
using the value of TZ at startup as it's timezone.
In addition, a GMT clock always appears.
..........
IMPLEMENTAION
-------------
Xchrono is yet another blatent hack of xclock. I modified the athena
Clock widget to allow for one timer callback to update all instances
of Clock widgets in a process. The class part of the clock widget
maintains a list of all instances of Clock.
The main window of xchrono is just a Box widget with an instance of
Clock for every desired timezone.
This is a hack. Hopefully it will inspire someone with more time and/or
motivation to do it right (and include nice things like a dialog box
to do dynamic configuration, etc...).
I think Ansi has something to say about implementing timezones, but
for now I just hacked in support for tztab (SYSV) and zoneinfo (BSD).
Good enough for now.
WARRANTY
--------
Yeah, right. :-)
Enjoy,
Nick Bender nick%bischeops@uunet.uu.netac1@chive.cs.reading.ac.uk (Andrew Cunningham) (07/01/90)
In article <HARKCOM.90Jun28165846@potato.pa.Yokogawa.CO.JP> harkcom@potato.pa.Yokogawa.CO.JP (Alton Harkcom) writes: > > Recently I tried to expand xclock to show the local time here and >the local time at my home. I am new to widgets so needless to say I spent > If you have a AT&T type timezone system then you can just run, for example, xclock -title "Local" & TZ=MST7MDT -title "Colorado" & Yours etc, | e-mail: ac1@csug.cs.reading.ac.uk Captain B.J. Smethwick |------------------------------------------ in a white wine sauce with | Nobody agrees with my opinions, though shallots, mushrooms and garlic. | everybody is entitled to them.