Hi Alex,
Yeah, we got off 7.2 maybe last July or so. It was an awful experience
trying to get everyone onboard. We are starting the process of looking
at v9.5 now. Give us 3 years...
Anyway, I did a little research on the CURRENT TIMEZONE special register
and it doesn't look viable. The value of the CURRENT TIMEZONE is
calculated as the difference between the "Local" application server and
the database server. Both the application and database servers are
located in the Eastern Time Zone. Bottom line would be, all of our
applications would have to be rewritten and any column with a time would
have to be converted.
I think the answer is that I can't do it. I will open an IBM PMR and
suffer through their support...
Thanks for researching the issue. It seems things are a little "thin"
with LazyDBA anymore. Perhaps everyone has become too lazy (or are
playing World of Warcraft).
Douglas Kostelnik
Senior Database Administrator/Architect
-----Original Message-----
From: Alex Levy
[mailto:db2udbdba-ezmlmshield-x35542282.[Email address protected]
Sent: Friday, May 09, 2008 11:36 AM
To: LazyDBA Discussion
Subject: RE: Fun with Time Zones...
Hi Doug
Long time no speak, and good to see you're off V7 at last!
I haven't faced this situation myself, so this is just the way I see it.
I
may be talking out of my backside, but you haven't had any replies
either,
so here goes: and this only applies to the Unix server world:
Unix server time is measured internally as seconds(current UTC timestamp
minus point in time 1970-01-01UTC00:00:00),
then the TZ env parameter is applied to that; and that gives the actual,
local time according to the server .......
To revert to an UTC/GMT equivalent time, a *local* client would
therefore
have to apply the current timezone special register in all queries.
Now if a *remote* client queries a server and that client is in another
time
zone, the value returned by the server will be the value shown at the
client, as the client will not alter the data returned by the server.
That's
logical.
A remote client in another timezone cannot use the current timezone
special
register because that holds the value of the server's timezone, not the
client's timezone. So if the remote client wants to see it in local
time,
the query has first to build in some hours expression other than the
current
timezone special register. In short the time conversion has to be
handled at
application or local query level.
http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.
ibm.
db2.udb.admin.doc/doc/r0005887.htm
As for Daylight Saving, let's not even go there on a Friday afternoon
(local
time). There's one way to test this on a local Windows client, that's by
changing the local timezone somewhere in the bottom right hand corner,
firing up a DB2 command window, connecting to a remote instance and
seeing
what happens.
Cheers
Alex
-----Original Message-----
From: Doug Kostelnik
[mailto:db2udbdba-ezmlmshield-x90242307.[Email address protected]
Sent: 8 May 2008 21:00
To: LazyDBA Discussion
Subject: Fun with Time Zones...
Greetings,
We have been sitting on this one since DB2 v1.2... We are currently on
DB2 UDB v8.2.
Our main server is in the Eastern Time Zone, but our branches span into
the Central Time Zone. I believe we've always had the CTZ computers set
to ETZ time and never really thought much about it for the past 14(?)
years. In the age of modern computing, someone suggested that we let the
CTZ users have their PC's set to their local time. Since time is stored
on the server in GMT (as I understand it), how do I get computers in two
different time zones to store and display the correct time.
Example:
Someone performs a sales transaction in Tennessee at creates a receipt
at 16:00. If the offset from GMT is 6 hours, then the time stored is
10:00 (again, as I understand it). If someone in the ETZ looks at the
transaction, would it not then display as 17:00?
How do I get computers in two different time zones that are using the
same source server to consistently store and display the correct time.
Does anyone currently do this out there? How do you over come the
(possible) paradox of displaying the same transaction in two different
time zones?
Douglas Kostelnik
Senior Database Administrator/Architect
------------------------------------------------------------------------
The information transmitted is intended only for the person(s) or entity
to
which it is addressed
and may contain confidential and or privileged material and should be
treated as a confidential
AAA Auto Club South communication. If the reader of this message is not
the
intended recipient, you
are hereby notified that your access is unauthorized, and any review,
dissemination, distribution, or
copying of this message including any attachments is strictly
prohibited.
========================================================================
---------------------------------------------------------------------
TO REPLY TO EVERBODY , PLEASE CLICK REPLY-ALL, NOT JUST REPLY
To post a dba job: http://jobs.lazydba.com
To Subscribe : http://www.LazyDBA.com
To unsubscribe: http://www.lazydba.com/unsubscribe.html
---------------------------------------------------------------------
TO REPLY TO EVERBODY , PLEASE CLICK REPLY-ALL, NOT JUST REPLY
To post a dba job: http://jobs.lazydba.com
To Subscribe : http://www.LazyDBA.com
To unsubscribe: http://www.lazydba.com/unsubscribe.html
DB2 & UDB email list listserv db2-l LazyDBA home page