Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!rutgers!ucsd!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!wuarchive!udel!new
From: new@udel.edu (Darren New)
Newsgroups: comp.sys.amiga.tech
Subject: Re: 1.4 request
Message-ID: <3824@nigel.udel.EDU>
Date: 10 Nov 89 18:19:12 GMT
References: <3753@nigel.udel.EDU> <455@stretch.MUN.EDU> <1989Nov10.083157.4844@agate.berkeley.edu>
Sender: usenet@udel.EDU
Reply-To: new@udel.edu (Darren New)
Organization: University of Delaware
Lines: 47

In article <1989Nov10.083157.4844@agate.berkeley.edu> mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes:
>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
>
>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.

Actually, I was trying to make it simple and compatible.  By specifying
the offset from UTC (ok, and the name too) you can allow programs to
figure out local time and UTC.  The user would have to change the
offset from GMT at the start/end of daylite savings just as he/she now
must change the clock.  My main intent was for (say) file servers or
data base handlers.  At the server end, the server would do an
Examine(), use local preferences to translate the DateStamp to UTC,
send the packet.  The client would get the packet, convert back from
UTC to local time using the client's preferences, and all is well.
I don't offhand see the need for anything more complex to be
built in.  If you need to really know the UTC time for a time in
the past, I suppose a library could be built to translate UTC into
local time for any time including ones in the past.  I still think
things should all be stored in local time.

>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). 

It came thru *.sources a while back.  I've downloaded it
if you want.  My point is that all this could be done
just by specifying the timezone name in Preferences.
Specifying the UTC offset allows programs to do simple
time translations of "right now" easily and without
other support.  Putting the timezone name in Preferences
allows 3rd party libraries (or standard libraries) to
be written to solve the much more complex problem
of translating arbitrary time into UTC and back.
I think it would be mostly pointless to use UTC
in things like FileInfoBlocks; it would be incompatible
and usually not needed.  On the occasion it is needed,
THEN use the standard library to translate.
		     -- darren