🚀 go-pugleaf

Date: Sun, 23 Feb 86 23:54:47 PST
From: seismo!s3sun!sdcsvax!sdcsvax.UCSD.EDU!allyn (Allyn Fratkin)

In article <4239@ut-sally.UUCP>, davidsen@steinmetz.UUCP (Davidsen) writes:
>   One method of solving these problems would be to use the value of TZ as
> the name of a file in a special directory. These files would be
> executable, and given the current date and time in GMT would return the
> number of minutes to be added to GMT for that timezone (obviously the
> return value is signed).

Problem here: on most unix systems the parent only gets the lower eight
bits of the exit value.  This would mean max/min values of 127/-128.
Not very practical if the value is supposed to be in minutes.
Fine if the return value is in hours, though, but then you're still 
leaving parts of the world out.  Besides, we've pretty much decided that
we should at least have precision in minutes.

Of course, we could make the precision HALF-hours.  This is kind of silly,
but is there anywhere in the world whose time is not an integral number of
half hours away from GMT?

[ The canonical example is Saudi Arabia, which has other problems, too. -mod ]

By the way, I definitely feel that we need both a per-system time zone
and a per-process (or per-user) time zone.  Machines are stationary,
but users are mobile (and sometimes far away).

(I imagine that timezone is not in the dictionary because its not a word).

[ Is filesystem a word?  -mod ]

-- 
 From the virtual mind of Allyn Fratkin            allyn@sdcsvax.ucsd.edu    or
                          UCSD EMU/Pascal Project  {ucbvax, decvax, ihnp4}
                          U.C. San Diego                         !sdcsvax!allyn

 "Generally you don't see that kind of behavior in a major appliance."
-- 
Allyn Fratkin                    allyn@sdcsvax.ucsd.edu
UCSD EMU/Pascal Project          or
U.C. San Diego                   {ucbvax, decvax, ihnp4}!sdcsvax!allyn

Volume-Number: Volume 5, Number 60