In a recent note, Petersen, Jim said:
> Date: Mon, 4 Dec 2006 17:14:59 -0500
>
> We are hearing from our SAP Server folks that although DB2 Time Stamps
> its logs with GMT even if you are using an offset, the records passed
> back to the SAP Servers contain LOCAL time which causes problems during
> Daylight Savings Time changes.
>
> We are getting severe pressure from our SAP folks to run the z/OS LPARs
> LOCAL=GMT.
>
OK. I'll retract some of my (perhaps excessively exuberant) praise
of IBM, at least in the area of DB2. I RTFM:
Title: DB2 UDB for z/OS V8 SQL Reference
Document Number: SC18-7426-03
and find:
2.15.1 General rules for special registers
Datetime special registers: The datetime registers are named CURRENT
DATE, CURRENT TIME, and CURRENT TIMESTAMP. Datetime special registers
are stored in an internal format. When two or more of these registers
are implicitly or explicitly specified in a single SQL statement, they
represent the same point in time.
But then:
To evaluate the references when the statement is being executed, a
single reading from the time-of-day clock is incremented by the number
of hours, minutes, and seconds specified by the TIMEZONE parameter. The
values derived from this are assumed to be the local date, time, or
timestamp ...
and:
___________________________________________________________________
2.15.24 CURRENT TIMEZONE
CURRENT TIMEZONE specifies the TIMEZONE parameter in the form of a time
duration. The data type is DECIMAL(6,0).
...
Example: Display information from SYSCOPY, but with the TIMESTAMP
converted to GMT. This example is based on the assumption that the
installation sets the clock to GMT
and the TIMEZONE parameter to the difference from GMT.
SELECT DBNAME, TSNAME, DSNUM, ICTYPE, TIMESTAMP - CURRENT TIMEZONE
FROM SYSIBM.SYSCOPY;
Conspicuously absent is any guarantee that in a single SQL statement
CURRENT TIMEZONE represents the same point in time as CURRENT DATE,
CURRENT TIME, and CURRENT TIMESTAMP. So I see a hazard that deriving
GMT as in the Example could result in an hour's error during some
timing window, however narrow. Properly, GMT should be the primitive
value and local time the derivative rather than vice-versa.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
