Operating System - Tru64 Unix
1748255 Members
3937 Online
108760 Solutions
New Discussion юеВ

Re: Clock change

 
Amanda Deer
Frequent Advisor

Clock change

Last weekend my Tru64 V5.1A systems didn't change to BST, they were still saying GMT. I had to adjust the time manually. This weekend though they have changed to BST and now are an hour fast. Any ideas why they changed on the wrong date?
16 REPLIES 16
Ivan Ferreira
Honored Contributor

Re: Clock change

Your zone file should be incorrect. Check with the zdump command:

zdump -v BST

You can modify your zone file and compile it with the right values, for detailed information see:

http://www.tldp.org/HOWTO/html_single/TimePrecision-HOWTO/#time

Por que hacerlo dificil si es posible hacerlo facil? - Why do it the hard way, when you can do it the easy way?
Howard Anderson_2
Frequent Advisor

Re: Clock change

I am runnning systems on 5.1B and 4.0G with an external hardware clock providing them with NTP. They all switched on the correct weekend.

Do you have any external hardware providing time synchronisation ?

Are you using NTP to synchronsie from the Internet ?

Do you have a record of what location you told the OS to be in when you first configured the OS ?
This should also be in /etc/svid3_tz.
Mine is set to :London
Yours could also be :GB-Eire

Off the top of my head the critical one is the /etc/zoneinfo/localtime symlink.
This should point to London or GB-Eire in the /etc/zoneinfo directory.



Amanda Deer
Frequent Advisor

Re: Clock change

We are using ntp, but the server we are using doesn't exist anymore. We have a cluster and I thought they were just synching between themselves. Which is the best way to tell where they are getting the time from?
Michael Schulte zur Sur
Honored Contributor

Re: Clock change

Hi,

you can do
cat /etc/ntp.conf

greetings,

Michael
Ivan Ferreira
Honored Contributor

Re: Clock change

Use ntpq -pn, the server with an '*' is your current time server.
Por que hacerlo dificil si es posible hacerlo facil? - Why do it the hard way, when you can do it the easy way?
Amanda Deer
Frequent Advisor

Re: Clock change

remote refid st t when poll reach delay offset jitter
==============================================================================
*127.127.1.0 127.127.1.0 12 l 21 64 377 0.000 0.000 0.000
10.0.0.1 10.0.0.2 14 u 11 1024 377 0.440 -0.538 0.000


This is the output from ntpq -pn. The man page says 127.127.1.0 is a reference clock.

server 127.127.1.0 version 3
fudge 127.127.1.0 stratum 12
peer dcs1b-ics0 version 3

This is /etc/ntp.conf.


Martin Moore
HPE Pro

Re: Clock change

Amanda,

What is the output of:

ls -l /etc/zoneinfo/localtime
I work for HPE
A quick resolution to technical issues for your HPE products is just a click away HPE Support Center
See Self Help Post for more details

Accept or Kudo

Amanda Deer
Frequent Advisor

Re: Clock change

lrwxrwxrwx 1 root system 15 Mar 31 2004 /etc/zoneinfo/localtime -> ./Europe/London
Martin Moore
HPE Pro

Re: Clock change

OK, now please try:

zdump -v Europe/London | grep 2006

This will dump the times in 2006 that the London timezone is scheduled to change. On a V5.1A lab system here, I get the following:

Europe/London Tue Apr 4 12:57:56 2006 BST
Europe/London Sun Mar 26 00:59:59 2006 GMT = Sun Mar 26 00:59:59 2006 GMT isdst=0 gmtoff=0
Europe/London Sun Mar 26 01:00:00 2006 GMT = Sun Mar 26 02:00:00 2006 BST isdst=1 gmtoff=3600
Europe/London Sun Oct 29 00:59:59 2006 GMT = Sun Oct 29 01:59:59 2006 BST isdst=1 gmtoff=3600
Europe/London Sun Oct 29 01:00:00 2006 GMT = Sun Oct 29 01:00:00 2006 GMT isdst=0 gmtoff=0

(The first line is just the current time when I executed the command.)

This shows that the timezone should have changed at the correct time, 01:00 on March 26.

Let's see whether your zdump output is the same and go from there.

Martin
I work for HPE
A quick resolution to technical issues for your HPE products is just a click away HPE Support Center
See Self Help Post for more details

Accept or Kudo