🚀 go-pugleaf

In article <455@stretch.MUN.EDU> sean2@stretch.UUCP (Sean Hogan) writes:
<In article <3753@nigel.udel.EDU> new@udel.edu (Darren New) writes:
<>I think it would be useful in the future to have a field in
<>preferences describing your timezone.  It should be
<>settable from -12 to +12 or "undefined" (the default).
<>This would allow programs that need UTC to
<>get to it without fouling up older programs or programs
<>that don't care.  Time on the system would remain as local
<>time.      -- Darren
<
<Please oh please, if anybody considers doing this, remember that some
<places in the world (yes, even in North America) do not operate on
<one-hour divisions of zone!

I vaguelly recall there are some 1/4 hour divisions floating around,
also. Could be wrong, though.

Of course, just allowing the user to specify an offset from UTC isn't
really an improvment over the current situation. All that does is
allow you to ask for (unspecified) local time, or UTC. That doesn't
seem very usefull to me. After all, what you _really_ want is that
offset, plus the _name_ of the timezone. Most people (in the US,
anyway) probably want to know whether they're on DST or not. Since the
latter is _very_ irregular, and variable by law, you really need some
kind of table the user can modify.

Fortunately, this problem has been dealt with elsewhere. It was done
to deal with the last time the US Congress decided to change the DST
rules (*), and should be mostly portable. Even if that's not, the
solution should be usable, suitabley tweaked for the Amiga
environment.

1a) Add to preferences a scrolling list similar to printers. The list
is the contents of devs:timezones.

or

1b) Add a "settz" command, similar to "setmap". It also uses
devs:timezones (doing both might be possible).

2) devs:timezones contains a set of binary files for the major
timezones. The binary file contains the TLA used for that TZ,
including the one for DST if it's apropriate. It also contains rules
for determing when DST goes into affect for any time in the past, as
well as the future. The extras disk should contain a program to turn
text files into timezone data files, with documentation.

3) libs:date.library containes routines for turning timestamps into
printable dates. When opened, it checks preferences (or an env:
variable - doesn't really matter) and loads the binary data from the
appropriate devs:timezones file.

4) The system utilties are converted to use the libs:date.library.
Other things follow as they wish.

5) The user, when they get the machine, sets the timezone, then sets
the clock to the correct time for their timezone. The utility for
setting the hardware clock sets it to UTC, and everything works from
there. The user never has to touch the clock again, barring glitches.

That's just one scenario. Seemed like the obvious one to avoid having
to read in the binary file every time you needed the date. Others are
possible. One key fact of this is that the code for most of this
_already exists_. I think it's PD (I'll find out ASAP). The other is
that this problem has been fought - and mostly defeated - before.
Instead of repeating the mistakes of others, we should learn from
them.

	<mike

(*) For those of you who don't follow such things, the US
Congresscritters are talking about changing it _again_, and moving the
fall dicontinuity back a couple of weeks on presidential election
years.
--
Lather was thirty years old today,			Mike Meyer
They took away all of his toys.				mwm@berkeley.edu
His mother sent newspaper clippings to him,		ucbvax!mwm
About his old friends who'd stopped being boys.		mwm@ucbjade.BITNET