mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (11/11/89)
In article <3824@nigel.udel.EDU> new@udel.edu (Darren New) writes:
<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.
Ah - I thought you were going to do it the other way around. Doing it
this way instead changes things - usually for the worse. I'm going to
re-arrange your text to group related items together.
<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.
[...]
<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.
Um, do you want the timestamps passed betweeen the client & server to
be correct? If so, then you need to be able to find out what the
correct offset was _at the time the file was created_. This means you
have to know whether or not DST was in effect at the time, so you need
all the baggage about timezones & DST rules.
<I still think things should all be stored in local time.
From the above, doing that creates a lot of headaches. You have to do
translations to/from UTC whenever you want to move the file (which you
can't do if you don't know it's being moved.) This means you have to
go through the DST tables to every time. Seems like a lot of overhead.
<I think it would be mostly pointless to use UTC
<in things like FileInfoBlocks; it would be incompatible
<and usually not needed.
It should be obvious that I don't think it's pointless. As for it
being incompatible, I'd like to know what standard it's incompatible
with. As far as I know, there's nothing that says that an Amiga must,
or even should, be set to local time. There are professions that
regularly work with UTC; I expect that you'll find some of them with
Amiga set that way. Nor does this break any software; all old software
would print the system time, just like it does now.
<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.
They would also still have to change the clock. Using UTC for the
system time eliminates that, but they'd still have to change that
offset. These two things are exactly the kind of mindless tasks that
computers do better than people. Assuming you got the program right.
<My point is that all this could be done
<just by specifying the timezone name in Preferences.
Not if files have local time datestamps. If they have UTC datestamps,
then you're right. I feel that if we're going to ask people to change
their system clocks from local time to UTC, we should arrange things
so they don't have to fool with them again. Yes, it's not a major
gain. Then again, it's not a major change.
<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.
This was basically what I suggested - a library that only needs to be
used if you want local time. This should only happen when you want to
show the user the time. Everything else is simple.
<It came thru *.sources a while back. I've downloaded it
<if you want.
That answers the question about PDness. I've still got the copies I
installed on my Unix systems, though. Thanks for the offer.
<mike
--
Come rain, come hail, come sleet, come snow Mike Meyer
You don't like to drive to slow mwm@berkeley.edu
You're always in the passing lane ucbvax!mwm
It's enough to drive me out of my brain mwm@ucbjade.BITNET