HP3000-L Archives

May 1999, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Stan Sieler <[log in to unmask]>
Reply To:
Stan Sieler <[log in to unmask]>
Date:
Thu, 20 May 1999 12:42:41 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (29 lines)
Tom writes:

> I have no idea how your database is set up, but it seems to me that all
> transactions should be timestamped and stored in your DB using a common
> timezone (GMT, maybe, or the timezone where the computer is physically
> located).  That way, all transactions will relate to each other correctly.
>
> All transactions should be displayed to the users in the users' local
> timezone.  Each time a transaction is displayed, the timestamp is

I agree...this is the same basic setup described by Cecile Chi at
IPROF earlier this year.

The one thing you *don't* want to do is use a date/time simulation tool
(any of them!) to try to solve this ... because it simply gets screwed
up, non-coherent times into your data.  The proper solution is to
translate the time from some standard (GMT or "system" or whatever) into
the user's local time using their timezone.  It's extra work in the
application, but necessary.

The other choice is to tell the user "hey, we're using PST time...get used to it" :)
The problem with this is that if they're getting any date/time info
from their local PC/computer/whatever, you won't have an automated method
of correctly converting it to "real" time.

--
Stan Sieler                                          [log in to unmask]
                                     http://www.allegro.com/sieler.html

ATOM RSS1 RSS2