Arthur Darren Dunham (add@is.rice.edu) writes:
Unix does not change the time during DST changes. Unix keeps track of
UCT (Zulu time, GMT) and applies an offset for your timezone. Your
timezone changes dunring DST, not the unix clock.
Depending on the circumstances, xntp can make both forward and backward
adjustments and can make large ones if it feels it is warranted.
catey (catey@wren.geg.mot.com) writes:
I've had xntpd running on my SunOS 4.1.3_U1 Oracle server for about a month.
At first all my clocks were off by 20 seconds (too fast) and were corectly
set back by xntp, without disrupting my database.
James Howard (James.A.Howard@nmb.norwest.com) writes:
Here at Norwest, we use nistime, to sync to the atomic clock, and then
rdate all our machines internally to the timehost. We have been doing this
for well over a year now without any problems. We use mostly Sybase
databases
but have some others as well.
twhite (twhite@bear.com) writes:
remeber - when times are changed is typically 2 a.m.
your best bet is to stop processes (cronjobs oracle ??whatever)
until after the time change and then kick them off..
I also found some information on the Progress Web site
http://www.progress.com
The time stamps are obtained from the current value of the
system time. The database manager gets the current system
time by using the system call time(), which returns the
current time and date in the form of elapsed seconds from
the start of the Epoch (00:00:00, January 1, 1970), in
Universal Coordinated Time or UCT. This was formerly known
as Greenwich Mean Time.
Note that the time() function must return the correct time
in order for the two usages described above to operate
correctly.
In all Unix systems, the system clock is supposed to be set
(and kept to) to UCT. Local time is established through the
use of the time-zone environment variable TZ. The system
automatically adjusts local time to take daylight savings
time into account without affecting the system time, which
is always in UCT. The Progress database manager does not
use local time for timestamps. It is thus unaffected by
changes in the value of local time.
However: not everyone operates their system in this manner.
Some people set the system clock to local time and make
manual adjustments for daylight saving time. This can cause
many programs, including Progress, to fail. Some other
examples of programs that might fail are cron, make, backup
utilities, etc. Any event that is associated with the time
and date may be handled incorrectly. Files may have
incorrect time stamps, e-mail may have the wrong date, etc.
The sections below describe how various releases of the
Progress database manager react when the system clock is
changed. Note that the clock may be changed for reasons
other than the change for daylight savings time. It does
not really matter what the reason is.
And an expert at the largest Oracle site in the world notes that the
internal
databases pay attention to a System Change Number, not local time.
SO.....
I don't have to be up at 2:00am. Really!
Thanks, everyone, for your replies.
Brian Hanna
Unix System Administrator
Minneapolis, MN
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:14 CDT