[part of an off-line conversation; it raises some questions that would
probably benefit from a broader perspective]

> But what you don't know is what the local time was where the time was
> stored.  Even if you store UTC, you need to store the time 
> zone to get back to the local time at that location.

Perhaps the first question to ask is "do I really need or want to see
times displayed in the source's local time?" I submit that much, perhaps
most, of the time the answer is "no". In the most common case, the users
are all in the same time zone, so they all see the same time anyway. For
a user halfway around the world from me, it is usually more useful for
me to see times in my local reference point. For example, the message to
which I'm replying was written last night at 22:49. Since I happen to
know that the sender and I are both in the same time zone, I know that
the message is about 14 hours old. However, if the source were in
Central Europe, the message header would still say that the message was
written at 22:49, and I would have to do the mental gymnastics to figure
out that it was really only a few hours old. It would be much more
useful for the message to show that it was written at 9:49 (or whatever
it would be for Central Europe) this morning, my time. 

Or consider a manufacturing operation with direct client quote requests.
I'm the operations supervisor, and I'm reviewing the unassigned quote
requests. I see a couple of requests that are both about an hour and a
half old. Perhaps a little long, but not too bad, considering that today
is Monday and we're also catching up on the weekend items. What I
*don't* pick up on is that one of the quote requests--from one of our
best customers--was entered from one of their Pennsylvania sites, and is
actually *four and a half* hours old! Ouch; one of my best customers has
been sitting for half a day waiting for us to acknowledge the request.

I'm sure there would be cases where it really would be necessary to know
the user-local time of a record; as suggested, it would be necessary in
those cases to store an indicator for the source time zone. But if those
situations are, as I suspect, a minority subset, it would be more space-
and time-efficient to default to UTC.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *