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
DB2 & UDB email list listserv db2-l LazyDBA home page