Good advice. I've been through this several times, the last required
entry and reporting to time zones around the world, a task for which
-- unfortunately -- the original system was not designed.
A possible transition approach: shut down external entry, convert all
date/times in the DB to GMT, set your system time to GMT, start
allowing external entry.
This should restrict code changes to reporting programs since the
entry system will continue to operate in a single time zone; it'll
just be GMT instead of Pacific time.
Of course it'd be nice to have all reporting programs changed so you
could transition to them at the same time and -- theoretically :-) --
no one would notice reporting differences except they'd be correct in
each time zone.
Stewart
-----Original Message-----
From: "Bob Woodward" <[EMAIL PROTECTED]>
My suggestion would be, since everything is currently written for a
single time zone, is to store everything in GMT then for
reports/displays/whatever, you can prompt for a timezone to convert to.
This way you're only updating programs instead of converting database
structure to add a timezone indicator and being forced into changing all
programs all at the same time. Convert your current datafiles by
updating times then update programs as needed. First push would be for
anything accepting time's to be updated but then all output programs
could be updated at a much less fevered pace. It's going to be painful
no matter what you do, I think.
Good luck!
BobW
-----Original Message-----
We recently expanded into a different time zone!
Our server time is syncronized to pacific time (daylight savings or
not).
Now we have electronic timecards as well as many other entry processes
being
performed
in a Mountain Time Zone.
...
Nancy Fisher
--
Stewart Leicester | JenSoft Technologies, LLC
"Per Ardua Ad Astra" | <mailto:[EMAIL PROTECTED]>
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
