Change system time back one hour

[Joe Profaizer]

I have system in South Africa that is displaying the time 1 hour ahead of what it should be.
# date
Fri Aug 26 12:20:22 SADT 2005

It really should be only 11:30:22. What does the DT mean after SA? SA"DT"?

I do plan on rebooting the server today, so I just want to change the time back one hour. Is there a preferred method instead of the just using the "date" command.

[Cem Tugrul · Accepted solution]

Hi Joe,
of course there are some methods;
go to SAM;
time-->sysclock
or
set_parms

also have a look at this links;
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=850635

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=847752

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=843029

Good luck,

[Cem Tugrul]

another useful links;

http://www5.itrc.hp.com/service/james/search.do?searchtext=timezone&hpl=1&todo=search&searchcriteria=allwords&from=forums&searchcategory=ALL&rn=25&presort=rank&source=7000&esc=europe.support.itrc.hp.com&wpa=forums1.itrc.hp.com%3A80&origin=0&chkServStor=on

[Pete Randall]

Joe,

The only caution with setting the clock back is if you're running a DataBase environment. It can cause havoc with your rollback logs. So just make sure your DB is not active when you set the clock.


Pete

[melvyn burnard]

To answer the following:
# date
Fri Aug 26 12:20:22 SADT 2005

It really should be only 11:30:22. What does the DT mean after SA? SA"DT"?

Years ago, HP-UX had entries in /etc/tztab for Sa that indicated SA had Daylight Savings Time, hence S(outh)A(frica)D(aylightSavings)T(ime)

SA does not have Daylight Savings Time, there are no changes during the year like UK etc.

When I worked there, we used ot have to create our own entries to fix this, but a few years ago this was corrected.

Check you tztab file, also your /etc/TIMEZONE entry.

[Yogeeraj_1]

hi

you may also wish to review your timezone.
(use echo $TZ )

you should use "set_parms timezone" to do the appropriate changes.

man set_parms
for more information.

hope this helps!

kind regards
yogeeraj

[Cem Tugrul]

Because Oracle tracks the sequence of events in the database using the System
Commit Number (SCN), changing the system clock for daylight savings time will
have no effect on database operation. The only point where the time change
can have potentially harmful effect is during time-based recovery.

Time based recovery requires checking of the actual time the transaction was
recorded in the logfile. Every log record has a time stamp associated with
it. If the system manager for some reason changes the system clock, Oracle
Support recommends shutting down the database and taking a cold backup ( or a
hot backup if preferred). If for some reason a dba has to go back to a backup
which was taken prior to the system clock change and rollforward, recovery
works just fine except for time based recovery (Note that time based recovery
works fine if the system clock is moved forward in time). When the system
clock is changed backwards, its possible that there could be two redo records
with the same time stamp. If time based recovery is done in this scenario,
since ORACLE applies only redo entries that were written prior to a specified
time, ecovery stops when it finds the first redo record which has that
specified time.

The following example will illustrate the problem:


3pm 4pm 4.15 4.30 5pm-->4pm 4.16pm 4.30 5pm
|--------------|-------|-------|-------|---------|-------|------|
cold/hot T1 T2 T3 clock T4 T5 T6
backup change

|<----------R1---------->|

A cold backup was taken at 3pm. A transaction T1 was done at 4pm. So the redo
record has a time stamp of 4pm. Transaction T2 was done at 4.15pm and
transaction T3 at 4.30pm.

At 5pm the system clock was changed backward, one hour. 16 minutes later (i.e;
at time 4.16pm) transaction T4 was done. Later on, the disk crashed and we
lost the databasefiles.

Any recovery done to recover data upto certain time in the range R1 will not
recover the data in the range R1 but recovers only until corresponding time
before the system clock change.

Say if the DBA decides to recover until T5(4:30pm) which is in time range R1.
DBA restores the backup from 3pm and does a recovery until 4:30 thinking it
would recover until T5. Actually the recovery is done until T3 and not T5. So
all the trasanctions entered after T3 will be lost. Recovery beyond 5pm or say
beyond range R1 should not cause any lose of data.

Note:
Although specifying a time in the interval 'clock change' to 'T6' will
result in incomplete recovery to the first occurrence of the specified
time it is still possible to recover to any point in time in this range
using SCN based recovery (using the RECOVER UNTIL CHANGE clause).

Conclusion:
Following a time change where the clocks go back in time there is a
window where INCOMPLETE recovery using TIME BASED recovery is affected.
Recovery to a point in time within this window can be achieved using
SCN (or CHANGE) based recovery.
Recovery to a point in time after this window requires no special action.
****************************************
What does this all mean?I do not think NTP is an issue.It regulates the
clock ticks.The issue seems to be a DB recovery issue with Logging and
Daylight Saving Time and this has been around forever.

[Steven E. Protter]

I would suggest using ntp to connect to a correct time server.

Then your clock will run slowly for the period of time needed to correct this problem.

Setting back time can crash oracle databases among other nasty impacts.

SEP

[Torsten.]

Hi Joe,

there is another method to adjust the clock SLOWLY.
#date -a -3600

do a man date and look for parameter "a".

HTH

[Bill Hassell]

I would not change the time at all because it is not necessary. HP-UX only keeps time in GMT (Zulu, UTC, etc) and what you see with the date command is a translated value.The reason is simple: Timezones have nothing to do with astronomy--they are 100% political and quite arbitrary. This is a great site to explain time problems: http://physics.nist.gov/GenInt/Time/world.html Knowing that, HP-UX was designed to handle any possible set of rules about time and time shifts like Daylight Saving Time.

Do you want to see the current time in California or New York? Use these commands:

TZ=PST8PDT date
TZ=EST5EDT date

Now you have to get your server onto the correct GMT time. Type this command:

TZ=GMT0 date

Is that the correct time for GMT (use this website to verify: http://www.firstscience.com/site/time.asp

If you need to change the time, to make GMT0 correct, read the warnings. Although Oracle doesn't track transactions by time, many DBA's will code time/date into fields making the database sensitive to time changes. As mentioned, you can slew the time so that no seconds are lost or gained but the time between seconds can be expanded or reduced until the time is correct. This is a standard feature of NTP (the xntpd program).

But it cannot adjust more than 1024 seconds (17 minutes) so a 'jump' change will be necessary. So schedule some downtime so you can stop all the applications and then change the date/time.

Now if GMT0 is correct, you simply need to change the default timezone. SADT does not seem to be in the sandard /usr/lib/tztab file (the original version is in /usr/newconfig/usr/lib/tztab so you can compare it:

diff /usr/newconfig/usr/lib/tztab /usr/lib/tztab

Since SADT does not appear in a normal tztab file, it may have been added to /etc/TIMEZONE without realizing that it will be ignored if there is no matching entry in tztab. This often happens when someone familiar with another flaovr of Unix makes changes based on the other system's rules. The command:

TX=SDAT date
and
TZ=XYZW date
and
TZTAB=GMT0 date

may produce the same result. So your time may indeed be displaying as GMT right now. Check if you get the correct time with:

TZ=SAST-2 date

This is the entry in tztab for South Africa. Now it does not have a Daylight Saving offset in tztab. The man page for tztab and the comments will help define the complete entry for tztab. Another really use page is: man environ where the TZ value and fields are defined. With the rules in environ, you can create any timezone with any offset (not just by hours) and any Daylight Saving Time offset.

Now it appears that South Africa uses GMT+2 with no Daylight Saving (from http://www.timeanddate.com/worldclock/ ) so the /etc/TIMEZONE file should read:

TZ=SAST-2
export TZ

That should fix your problem once the GMT0 time is correct.

[Joe Profaizer]

Bill,
GMT time on my system is one hour early than posted on the web site you referenced. I'm not sure how to change the GMT back one hour.

[Bill Hassell]

You'll have to do it at a time that won't affect your applications, perhaps on the weekend, late at night, etc. Shutdown all your applications, then use the date command to set the time back one hour. When you do, GMT0 time also goes back one hour. Now restart your applications.

[Joe Profaizer]

Thank you everyone!!

[Joe Profaizer]

Very good information. The /etc/TIMEZONE was key.