Hello all,
I hope someone can help me.
We have Compaq Tru64 UNIX V5.1B (Rev. 2650).
By latest Belarus government act Europe/Minsk timezone was changed to
GMT+3 without DST (was GMT+2 with DST).
Please advice how to do changes on our machine.
Thank You in advance,
md1982
I don`t know Tru64 at all. But i think you can use timezone just like you need if it exists in your system. Is there any that would fit?
I guess that you haven`t got support contract?
Hi,
I would like to change TZ to one that has the same rules as new one for Belarus, and that is Asia/Qatar.
Can You point me how to do that, just to do:
# ln -sf /etc/zoneinfo/Asia/Qatar /etc/zoneinfo/localtime
Is it required restart of server?
Will it have permanently effect, I mean will not change back to previous values?
Tnx,
md1982
look at the zic(8) man page to change this (see /etc/zoneinfo/timezones too) the correct way (I think an example is given). And make sure you don't have a TZ environment variable defined. I can help much for its 8 years since last time I saw a tru64...(I may still have mans at home but its asking for digging...)
First tnx for fast replay.
I have few more questions, first is how can I check if TZ environment variable is defined or not, and why is important that is not defined.
I have found this in man pages
"Setting Time Zone Information
The /etc/zoneinfo/localtime link can be changed by the system administrator
to any file in the /etc/zoneinfo directory.
For example, the following command changes the local time zone to be con-
sistent with the city of New York on the American continent:
# ln -sf /etc/zoneinfo/America/New_York /etc/zoneinfo/localtime"
That is why I have asked is that correct?
But in suggested from you man zic there is other example so Im not sure:
EXAMPLES
The following examples show how you use the time zone commands and data-
bases. You must be logged in as superuser (root) to use the following com-
mands:
1. Use a procedure similar to the following if a system is relocated to a
new timezone. This example uses Australian time zones and shows what
you need to do when relocating a host system from from Brisbane
(Queensland) to Sydney (New South Wales):
a. Verify the value of the link file /etc/zoneinfo/localtime as fol-
lows:
# ls -l /etc/zoneinfo/localtime
lrwxrwxrwx 1 root system 18 Mar 19 17:05 localtime -> \
./Australia/Queensland
b. If necessary, use the zdump command to verify transitions in the
target time zone as follows:
#zdump -c 2001 -v Australia/NSW
Australia/NSW Fri Dec 13 20:45:52 1901 GMT = Fri Dec 13 15:45:52 1901 EST \
isdst=0 gmtoff=-18000
Australia/NSW Sat Dec 14 20:45:52 1901 GMT = Sat Dec 14 15:45:52 1901 EST \
isdst=0 gmtoff=-18000
Australia/NSW Sun Mar 31 06:59:59 1918 GMT = Sun Mar 31 01:59:59 1918 EST \
isdst=0 gmtoff=-18000
Australia/NSW Sun Mar 31 07:00:00 1918 GMT = Sun Mar 31 03:00:00 1918 EWT \
isdst=1 gmtoff=-14400
Australia/NSW Sun Oct 27 05:59:59 1918 GMT = Sun Oct 27 01:59:59 1918 EWT \
isdst=1 gmtoff=-14400
.
.
.
(output truncated)
c. Delete the /etc/zoneinfo/localtime link as follows:
# rm /etc/zoneinfo/localtime
d. Create a new /etc/zoneinfo/localtime link, specifying the target
time zone as follows:
# ln -s /etc/zoneinfo/Australia/NSW localtime
#ls -l localtime
should now be: localtime -> ./Australia/NSW
check the transitions have changed using zdump
Verify the new link as follows:
# ls -l /etc/zoneinfo/localtime
lrwxrwxrwx 1 root system 18 Mar 19 17:05 /etc/zoneinfo/localtime -> \
./Australia/NSW
e. Repeat the zdump command in Step b to verify transitions in the
target time zone.
2. The system time automatically changes for events such as Daylight Sav-
ings Time. These time transitions are stored in the /etc/zoneinfo
database. If necessary, you can verify and alter the rules that
specify when a system will automatically alter its time. This example
shows how you change the active /etc/zoneinfo file to include the
changes to Daylight Savings Time. (Such a change was mandated for the
2000 Olympics, moving the start date of Daylight Savings Time to
August 27th in 2000, rather than the expected date of October 29th.)
The example assumes that the system is located in Sydney, Australia:
a. Examine the active time zone setting as follows:
# ls -l /etc/zoneinfo/localtime
lrwxrwxrwx root system 18 Mar 19 17:05 etc/zoneinfo/localtime -> \
./Australia/NSW
b. Use the zdump command to verify the time transitions for the
active time zone.
The zdump command prints transitions for every year since the
beginning of rules for the active timezone. Use the more command
or redirect (>) the output to a file so you can find the relevent
transition. Use the -c option to specify the year at which the
display output terminates. For example:
# zdump -c 2002 -v Australia/NSW
Australia/NSW Sat Oct 30 15:59:59 1999 GMT = Sun Oct 31 01:59:59 1999 EST \
isdst=0 gmtoff=36000
Australia/NSW Sat Oct 30 16:00:00 1999 GMT = Sun Oct 31 03:00:00 1999 EST \
isdst=1 gmtoff=39600
Australia/NSW Sat Mar 25 15:59:59 2000 GMT = Sun Mar 26 02:59:59 2000 EST \
isdst=1 gmtoff=39600
Australia/NSW Sat Mar 25 16:00:00 2000 GMT = Sun Mar 26 02:00:00 2000 EST \
isdst=0 gmtoff=36000
Australia/NSW Sat Oct 28 15:59:59 2000 GMT = Sun Oct 29 01:59:59 2000 EST \
isdst=0 gmtoff=36000
Australia/NSW Sat Oct 28 16:00:00 2000 GMT = Sun Oct 29 03:00:00 2000 EST \
isdst=1 gmtoff=39600
Each pair of lines for the same date and time shows a time tran-
sition. On Sun Oct 29 2000 immediately after 01:59:59 the time
changes to 03:00:00. This transition changes the local time from
Australian Eastern Standard Time (EST) to Daylight Savings Time
(DST). The value of the isdst field changes as follows:
+ 0 - Not Daylight Savings Time
+ 1 - Daylight Savings Time
The gmtoff field displays the offset from Greenwich Mean Time.
c. Display the contents of the /etc/zoneinfo database file for your
locale to find the rules for the local zone. In this case, it is
New South Wales:
# more /etc/zoneinfo/sources/australasia
.
.
# New South Wales
# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S
Rule AN 1971 1985 - Oct lastSun 2:00s 1:00 -
Rule AN 1972 only - Feb 27 2:00s 0 -
Rule AN 1973 1981 - Mar Sun>=1 2:00s 0 -
Rule AN 1982 only - Apr Sun>=1 2:00s 0 -
Rule AN 1983 1985 - Mar Sun>=1 2:00s 0 -
Rule AN 1986 1989 - Mar Sun>=15 2:00s 0 -
Rule AN 1986 only - Oct 19 2:00s 1:00 -
Rule AN 1987 1999 - Oct lastSun 2:00s 1:00 -
Rule AN 1990 1995 - Mar Sun>=1 2:00s 0 -
Rule AN 1996 max - Mar lastSun 2:00s 0 -
# Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone Australia/Sydney 10:04:52 - LMT 1895 Feb
10:00 Aus EST 1971
10:00 AN EST
Zone Australia/Broken_Hill 9:25:48 - LMT 1895 Feb
10:00 - EST 1896 Aug 23
9:00 - CST 1899 May
9:30 Aus CST 1971
9:30 AN CST 2000
9:30 AS CST
<display truncated>
From this display, you find the rules that apply to the current
year. For the year 2000 the rules are as follows:
Rule AN 1996 max - Mar lastSun 2:00s 0 -
The other rules either end on a past year or apply only for the
year specified, as shown in the TO column. The entry max in the
TO column means that the rule applies from the year listed in the
FROM column and for all future years.
d. Assume that on the last Sunday of October in 2000, you must
change the time at 2:00 a.m. to be one hour more than the stan-
dard time (EST). On the last Sunday of March, you must change
the time at 3:00 a.m. to be the same as EST, turning the clock
back one hour when the previous rule was active. (In this exam-
ple, the 27th happened to be the last Sunday in August, making
the transition change less complicated.) The new rule that you
must add is as follows:
Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S
Rule AN 2000 only - Aug lastSun 2:00 1:00 -
e. To avoid corrupting the /etc/zoneinfo/sources/australasia data
file, copy it to a backup revision as follows:
# cp /etc/zoneinfo/sources/australasia \
/etc/zoneinfo/sources/australasia.orig
Then edit the file /etc/zoneinfo/sources/australasia with a text
editor to add the following line:
Rule AN 2000 only - Aug lastSun 2:00 1:00 -
f. You can now use the zic command to update the database with the
new transition rule as follows:
# /usr/sbin/zic /etc/zoneinfo/sources/australasia
g. Use the zdump command to verify the new transitions as follows:
# zdump -c 2002 -v Australia/NSW
.
.
.Australia/NSW Sat Aug 26 15:59:59 2000 GMT = Sun Aug 27 01:59:59 2000 \
EST isdst=0 gmtoff=36000
This truncated output indicates that the transition to Daylight
Savings Time moved from October 29 to August 27, as required.
echo $TZ
echo $TZ
TZ: Undefined variable.
So undefined...
so what I have to do will be:
1) delete the /etc/zoneinfo/localtime link as follows:
# rm /etc/zoneinfo/localtime
2) Create a new /etc/zoneinfo/localtime link, specifying the target time zone as follows:
# ln -s /etc/zoneinfo/Asia/Qatar /etc/zoneinfo/localtime
???
And hop Qatar don't change their mind in the future...
Have you any HP support? If so look at this link that explains how it works:
https://h20566.www2.hp.com/portal/site/hpsc/template.PAGE/public/kb/docDisplay/?javax.portlet.tpst=ba847bafb2a2d782fcbb0710b053ce01&javax.portlet.prp\_ba847bafb2a2d782fcbb0710b053ce01=wsrp-navigationalState%3DdocId%25253Demr_na-c01411278%25257CdocLocale%25253Den&javax.portlet.begCacheTok=com.vignette.cachetoken&javax.portlet.endCacheTok=com.vignette.cachetoken
P.S. Don't forget to use code tags for your code and data...
Unfortunately I dont have any HP support.
What do you mean with code tags?
To keep the forums high quality for all users, take the time to format your posts correctly.
First of all, use Code Tags when you post any code or data samples so others can easily read your code. You can easily do this by highlighting your code and then clicking on the # in the editing menu. (You can also type code tags
```text
and
```
by hand.)
Second, avoid adding color or different fonts and font size to your posts. Selective use of color to highlight a single word or phrase can be useful at times, but using color, in general, makes the forums harder to read, especially bright colors like red.
Third, be careful when you cut-and-paste, edit any odd characters and make sure all links are working property.
Hope HP will forgive me...
Hi,
I have one more question, regarding this topic.
If is there some application on top of this, dose it require stopping of traffic to this server and rebooting or not.
I did not find any information to stop and reboot or not.
Tnx,
Mario
Only you can answer to this, we have no idea what your server is running...
If you can afford a reboot do so!
Now depending what was running (database? ) the issues you will encounter are more to do with what will the TZ have for effect, normally (well HP-UX anyway) changing the Time zone should not have side effects since it is using in internal UTC ( meaning reboot not necessary) but what do the applications running use? the side effects with schedulers are unpredictable... (shutdown the scheduler is a MUST here) so stop all applications.
Is it going back in time or forward after change? The possible issues with application will arise if going back in time ( applications hate to see it wrote in the future...)