Re: Best practice for TOD clock
- From: gilmap@xxxxxxxxxxxx
- Date: 10 Nov 2005 07:04:17 -0800
In a recent note, Wayne Driscoll said:
> Date: Thu, 10 Nov 2005 07:54:37 -0600
>
> DB2, like most IBM products these days (and a vast majority of other
> vendors) ONLY care about the UTC (which has replaced, and is more precise
> than GMT) time, especially for log records. For example, the bind timestamp
> (consistency token) is generated via the STCK machine instruction, which
> returns the UTC time. One GREAT reason for using UTC time with local time
>
Ummm. Not exactly. For the recommended setting of the TOD clock, STCK
returns not UTC, but IAT - 10 seconds. I recognize that this is
dependent on the choice of representation, but for the most simply
described representation it's IAT - 10 seconds.
> offsets is that you don't need to bring your system down (unless you have
> local applications that log with local time) for one hour in the fall.
> Since the UTC is always increasing, there is no possibility of getting
> duplicate timestamps if the timestamps are using UTC time. HOWEVER: (and
> this may be a BIG issue) If you are geographically located West of the
> meridian, when you convert over to UTC time, you will need to be down for
> the number of hours west you are, in order to prevent duplicate timestamps
>
If "the meridian" you mention is the Greenwich (or Prime) meridian,
the difficulty occurs east of the meridian, not west.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
.
- Prev by Date: RE: Best practice for TOD clock
- Next by Date: Re: Best practice for TOD clock
- Previous by thread: RE: Best practice for TOD clock
- Next by thread: Re: Best practice for TOD clock
- Index(es):
Relevant Pages
|
