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----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nancy Fisher Sent: Thursday, April 06, 2006 10:30 AM To: [email protected] Subject: [U2] TIME Windows 2003 / UniVerse 10+ 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. Of course all of the processes continue to show Pacific Time: on the timecards and delivery times reported to customers. I suppose there is no easy fix for this? Shortsighted maybe, but we've been happy for 55 years in a single time zone! Does anyone have any suggestions for us? We also have drivers who cross time zones now...will clock in at one time zone and clock out in another. I'm just wondering how others might handle UniVerse / SB+ applications across zones, especially since all processes were built with only one timezone in mind. Thanks for any and all suggestions! Nancy Fisher [EMAIL PROTECTED] ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
