Time set change

VIGNOLA,ALESSANDRO — Tue, 20 Oct 2009 14:55:12 GMT

Hello,
next wekend in CEt there'll be the hour change.
My customer has an Sap environment with hpux 11.31 server and he wants to change time set in the afternoon stopping and restarting SAP and not waiting till the 03:00 AM [the clock will be set to 02:00AM]. Well, how we can excluse the automatic time set that will be started at 03:00 AM CET? regards.
Alessandro

Re: Time set change

James R. Ferguson — Tue, 20 Oct 2009 15:07:13 GMT

Hi:

Daylight Saving adjustments are handled automatically and NO CHANGE in the system's time should need to be made. The operating system (and any half-way intelligent) database should be tracking in UTC (Epoch seconds). The UTC time does not change. What changes is your _perception_ of local time and that is governed in HP-UX by your TZ setting.

See the manpages for 'cron' for more information:

http://docs.hp.com/en/B2355-60130/cron.1M.html

Regards!

...JRF...

Re: Time set change

Larry Klasmier — Tue, 20 Oct 2009 16:40:41 GMT

James' explanation is very good. Just want to add if you change the time as your customer suggests you will potentially be creating big problems. Time synchronization will not work, additionally, UTC will be off which could create the problems your customer is trying to avoid

Re: Time set change

Matti_Kurkela — Tue, 20 Oct 2009 22:22:50 GMT

First, a bit of background:

Actually, the DST transition in Unix is not an one-time event, but a consequence of a conversion function that runs the same way each time a timestamp value is converted to human-readable local time.

If you program a Unix system to add two hours to a timestamp of 2009-10-25 01:30 AM and print the result in human-readable form, and your system's default timezone is CET-1CETDST (as it should be for Central Europe), the following happens:

1.) The system notices that the original timestamp does not have a timezone specified, and uses the default timezone instead.

2.) The system checks /usr/lib/tztab data (that was read to memory when the program was started) and sees that 2009-10-25 01:30:00 AM is DST time.

3.) The system converts the timestamp to UTC-equivalent time_t form. The result is 1256427000 (= seconds since 1970-01-01 00:00:00 UTC).

4.) To add 2 hours, the system simply adds 2 * 60 * 60 = 7200 seconds to the time_t value.
The result is 1256434200.

5.) This result is then converted back to human-readable form using the ctime() or localtime() function. /usr/lib/tztab data indicates this is supposed to be CET Standard time, so the non-DST conversion is applied. The output will be (if a default C locale is used):

Sun Oct 25 02:30:00 CET 2009

Note that the output is *not* ambiguous: it includes the timezone specifier which tells you whether the timestamp is DST or Standard time (CET for Standard and CETDST for DST time).

If the output of the ctime() or localtime() system function is processed in an application and the application ignores the timezone specifier and then becomes confused by "ambiguous" times, the application has a bug and should be fixed.

Note that *nothing* in the conversions listed above was dependent on whether the *current time* was Standard or DST. All the operations were based on the inputted timestamp and the system's timezone data only.

---------------

If your customer really wants to go through his suggested procedure, it will require stopping SAP twice:

- First, you must restart SAP before the DST transition using a custom value in the TZ environment variable, to make the SAP processes keep using the UTC+2 offset through the actual DST transition. A suitable TZ value would probably be TZ=CETDST-2.
(Yes, the offset sign is inverted in the TZ variable. Blame POSIX.)

Of course, a proper change management procedure requires testing this change in a test environment before applying it to a production SAP. It may be that it's already too late to do proper testing, as you don't have a spare weekend for testing end-of-week jobs...

You should probably do the same thing to the cron daemon, if you have defined cron jobs related to SAP.

- Second, you must stop SAP again in the afternoon after the DST transition, restore the TZ environment variable to the correct value, and restart SAP.

Your customer's suggestion actually requires significantly more work than doing it the correct way.

Note that changing the system's /etc/TIMEZONE is actually optional. The Unix system was originally designed to work with multiple timezones, e.g. with users all across the U.S.A using dial-up terminal connections to a server in a central location.

By setting the TZ variable accordingly in the beginning of a session, each user could use applications and see all time values automatically converted to his/her local timezone. This feature still works as designed. By changing the TZ variable before starting a process, you can cause the process to use a different timezone/DST rules regardless of the system's default settings.

MK

Re: Time set change

Suraj K Sankari — Wed, 21 Oct 2009 01:31:08 GMT

Hi,
No need to worry just open the below link download the patch according to your OS Version, Install the patch and forget.
Patch will take care of your DST time change.

i.e. after 3:00AM clock will automatically set to 2:00AM

http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&objectID=c00832124

Suraj

topic Re: Time set change in Operating System - HP-UX

Time set change

Re: Time set change

Re: Time set change

Re: Time set change

Re: Time set change