david@twg.com (David S. Herron) (06/20/91)
A customer wants to have a row of clocks showing different timezones.
Unfortunately the clock widget doesn't handle that case very well.
But a little simple hackery should suffice. Changes follow. This
is relative to R4/lib/Xaw/Clock{.c,P.h,.h} distributed from MIT and
patched to patchlevel 18.
--------------> Clock.c <-------------
static XtResource resources[] = {
...
{XtNhourOffset, XtCInterval, XtRInt, sizeof(int),
offset(hourOffset), XtRImmediate, (caddr_t) 0 },
};
...
/* ARGSUSED */
static void Initialize (request, new)
Widget request, new;
{
...
while (w->clock.hourOffset > 12) /* Normalize the offset */
w->clock.hourOffset -= 12;
while (w->clock.hourOffset < -12)
w->clock.hourOffset += 12;
...
}
...
/* ARGSUSED */
static void clock_tic(client_data, id)
caddr_t client_data;
XtIntervalId *id;
{
...
(void) time(&time_value);
time_value += (w->clock.hourOffset * 60 * 60);
tm = *localtime(&time_value);
...
}
--------------> Clock.h <-------------
/* Parameters:
...
hourOffset Interval int 0 (hours)
...
*/
...
/* Int: Value to add to the hours, half-assed way to display different timezones */
#define XtNhourOffset "hourOffset"
--------------> ClockP.h <-------------
/* New fields for the clock widget instance record */
typedef struct {
...
int hourOffset; /* How much to offset the hours ... */
...
} ClockPart;
David
--
<- David Herron, an MMDF & WIN/MHS guy, <david@twg.com>
<-
<-
<- "MS-DOS? Where we're going we don't need MS-DOS." --Back To The Futurepmartz@undies.dsd.es.com (Paul Martz) (06/21/91)
In article <9129@gollum.twg.com>, david@twg.com (David S. Herron) writes: > A customer wants to have a row of clocks showing different timezones. > Unfortunately the clock widget doesn't handle that case very well. > But a little simple hackery should suffice. Changes follow. This > is relative to R4/lib/Xaw/Clock{.c,P.h,.h} distributed from MIT and > patched to patchlevel 18. > > [... changes deleted ...] > > David > > -- > <- David Herron, an MMDF & WIN/MHS guy, <david@twg.com> > <- > <- > <- "MS-DOS? Where we're going we don't need MS-DOS." --Back To The Future A while ago someone posted the following script to this newsgroup. I think it does what you want, and alot simpler than the changes you describe. --- cut here --- #! /bin/sh TZ=PST8PDT export TZ xclock -geometry 70x70+3+0 -title PST 2> /dev/null & sleep 1 TZ=MST7MDT export TZ xclock -geometry 70x70+130+0 -title MST 2> /dev/null & sleep 1 TZ=CST6CDT export TZ xclock -geometry 70x70+257+0 -title CST 2> /dev/null & sleep 1 TZ=EST5EDT export TZ xclock -geometry 70x70+384+0 -title EST 2> /dev/null & --- cut here --- -- -paul pmartz@dsd.es.com Evans & Sutherland
guy@auspex.auspex.com (Guy Harris) (06/22/91)
>A customer wants to have a row of clocks showing different timezones. >Unfortunately the clock widget doesn't handle that case very well. >But a little simple hackery should suffice. Even less hackery should suffice on modern UNIX systems that understand the TZ environment variable (4.3-tahoe and later, SunOS 4.0 and later, S5-based systems, etc.) - just run "xclock", or whatever, with TZ set to the appropriate time zone. (How well it deals with daylight savings time, of course, depends on how well the code that handles TZ deals with it; systems with the Arthur Olson time zone code, such as 4.3-tahoe and later, SunOS 4.0 and later, System V Release 4, and others, handle it quite well.)
david@twg.com (David S. Herron) (06/24/91)
In article <8488@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >>A customer wants to have a row of clocks showing different timezones. >>Unfortunately the clock widget doesn't handle that case very well. >>But a little simple hackery should suffice. > >Even less hackery should suffice on modern UNIX systems that understand Hey.. I'm not dumb! Even I know about the TZ environment variable. However the requirements were to have multiple clocks for various time zones all in the same window. Therefore all the widgets would be in the same process & be subject to the same TZ variable. Somebody mentioned a program: 'xchron' which does pretty much what the effect of my patches was. BTW.. I feel that the clock widget definitely *should* have a resource setting for which time zone to display. After all the code doesn't always run on Unix so the TZ variable isn't always available. David -- <- David Herron, an MMDF & WIN/MHS guy, <david@twg.com> <- <- <- "MS-DOS? Where we're going we don't need MS-DOS." --Back To The Future
guy@auspex.auspex.com (Guy Harris) (06/25/91)
>BTW.. I feel that the clock widget definitely *should* have >a resource setting for which time zone to display. After all >the code doesn't always run on Unix so the TZ variable isn't >always available. So what would it do with that setting? A resource giving just an offset from GMT isn't sufficient for all purposes, for obvious reasons....
dce@smsc.sony.com (David Elliott) (06/25/91)
In article <8508@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) writes: |> >BTW.. I feel that the clock widget definitely *should* have |> >a resource setting for which time zone to display. After all |> >the code doesn't always run on Unix so the TZ variable isn't |> >always available. |> |> So what would it do with that setting? A resource giving just an offset |> from GMT isn't sufficient for all purposes, for obvious reasons.... It seems to me that the point of this resource would be to force some kind of system-independent behavior. We could define a set of values that would be "sufficient for all purposes". Since we're out here in Unix-land, we could define the syntax for TZ to be sufficient. I doubt that many non-Unix systems would find this to be insufficient for most purposes. I personally wouldn't mind seeing xchrono's Clock widget being made the standard Athena Clock widget. The location, AM/PM, and date labels make it useful all alone. -- ...David Elliott ...dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce ...(408)944-4073 ..."Art is never fair" - paa
boutin@hansen.ncd.com (Paul Boutin) (06/26/91)
In article <8488@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) writes: |> |> Even less hackery should suffice on modern UNIX systems that understand |> the TZ environment variable (4.3-tahoe and later, SunOS 4.0 and later, |> S5-based systems, etc.) - just run "xclock", or whatever, with TZ set to |> the appropriate time zone. (How well it deals with daylight savings |> time, of course, depends on how well the code that handles TZ deals with |> it; systems with the Arthur Olson time zone code, such as 4.3-tahoe and |> later, SunOS 4.0 and later, System V Release 4, and others, handle it |> quite well.) Guy, I suspect that you are an accomplished Unix programmer, given your use of the adverb "just" in the above sentence :-). I much prefer a straight offset from current local time, although I opted for specifying minutes instead of hours, so I can make up for skewed system times and also set my desk xclock ten minutes fast on meeting days. TZ is useful, but try to figure out that it even exists, let alone how to specify it, if you're a new or infrequent user... -- Paul Boutin Network Computing Devices 1000 Escalon Ave #3116 350 North Bernardo Ave Sunnyvale CA 94086 Mountain View CA 94043 408 738 8463 415 691 2115 boutin@ncd.com boutin@mit.edu
mouse@lightning.mcrcim.mcgill.EDU (der Mouse) (06/27/91)
>> Even less hackery should suffice on modern UNIX systems that >> understand the TZ environment variable [...] > Guy, I suspect that you are an accomplished Unix programmer, given > your use of the adverb "just" in the above sentence :-). I don't think there's much doubt of Guy's experience :-) > I much prefer a straight offset from current local time, although I > opted for specifying minutes instead of hours, so I can make up for > skewed system times and also set my desk xclock ten minutes fast on > meeting days. My clock specifies the offset in seconds, and allows the value to be floating-point. It also allows much more elaborate configuration. Pick up a copy from 132.206.1.1 (X/mclock.shar) and look it over. > TZ is useful, but try to figure out that it even exists, let alone > how to specify it, if you're a new or infrequent user... True. UNIX is generally not very good at helping such users to figure things out. (Once you know where to look (ctime(3) on our systems, for example), it's easy - but try to find that "where" cold....) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
guy@auspex.auspex.com (Guy Harris) (06/30/91)
>It seems to me that the point of this resource would be to force some >kind of system-independent behavior. We could define a set of values >that would be "sufficient for all purposes". Since we're out here in >Unix-land, we could define the syntax for TZ to be sufficient. Yes, but *whose* syntax for "TZ"? The old one used up to SVR3.1? The SVR3.1 one? The POSIX one? The one used in more and more UNIX systems, i.e. POSIX with the added stipulation that if the name starts with ":", the rest of the name is a pathname - relative to the default timezone directory if it doesn't begin with "/" - for an Arthur Olson-style timezone file? >I doubt that many non-Unix systems would find this to be insufficient for most >purposes. They wouldn't, but they might find some tricky to implement - especially the last, unless they pick up the Arthur Olson code and actually load up time zone files.
guy@auspex.auspex.com (Guy Harris) (06/30/91)
>I much prefer a straight offset from current local time, although I opted >for specifying minutes instead of hours, so I can make up for skewed system >times and also set my desk xclock ten minutes fast on meeting days. That's solving a different problem - the time zone problem isn't necessarily a straight offset from current local time (e.g., in the US and Canada, not all areas observe DST). In fact, you might want a clock that solves *both* problems, e.g. if your system time is skewed *and* you need to know what time it is halfway around the globe. >TZ is useful, but try to figure out that it even exists, The way to tell new or infrequent users that TZ exists is to document it - preferably in, say, the "how you use your whizzo new clock program" manual page or whatever. (It'd *still* probably be less complicated than the documentation for my watch - and mine's a fairly simple-minded one. :-)) (No, don't just mention it in the documentation for the widget; it's a pain in the neck having to check the Athena Widgets documentation, which is rather programmer-oriented, if all you want to do is customize the Text widget so that you can cut or copy to the Clipboard.) > let alone how to specify it, if you're a new or infrequent user... If I want to know what time it is in Japan, I generally just set TZ to "Japan" and run "date". I *did* say "systems with the Arthur Olson code", after all. :-) I.e., in systems with AO time zone code, the strings you set TZ to are (unless you're a pervert who actually *likes* the S3/S5/POSIX/etc. standard syntax :-)) character strings reasonable, at least, to English speakers (although the European time zones have names like "MET" and "WET" and "EET"). You might still need a table that says what the names for various time zones are, but your average user probably doesn't even know how many different sets of time zone rules there are (if you have a system with the AO code, and the vendor supplied the source to the rules files, take a look at them - it's an educational experience; they're in "/usr/share/lib/zoneinfo" in SunOS 4.x, in "africa", "antarctica", "asia", "australasia", "europe", "northamerica", "pacificnew", and "southamerica"), so they'd probably need to have all the time zones enumerated *anyway* - you might as well give the TZ setting names while you're at it.