Incorrect TimeZone variable!

[Becke]

Dear Guys,

we have got a incorrect timezone variable set, so as part of the daylight savings the time did not get changed automatically,the daylight savings was last week and we have gone 1HR backward, now my question is, if i change and set the correct timezone variable and reboot the system, would it go 1HR backward and recognize the new time or not???

This is a production server so I don't want to take any chances, please advise

[Peter Godron · Accepted solution]

Hi,
what is your timezone set to ?
Last Sunday you should have gone back 1 hour, which is what you say happened ?!

I hope you did not adjust the time with the date command? If you have and you now change the timezone, I suspect it would jump back another hour, as you have told it the 'wrong' starting time.

My info about u=your DST is from:
http://wwp.greenwichmeantime.com/time-zone/australia/daylight-savings-time/

[Dennis Handly]

>we have got a incorrect timezone variable set

Then just correct TZ and go about your business. ;-)

Or is this variable used for cron and networking demons where it would be nice if they were set correctly?

Make sure that "date -u" shows the proper UTC time.

Also make sure that if you manually set TZ, the date command gives you what you want, before you reboot:
$ TZ=xxx date

[Becke]

Thanks Peter and Dennis for your quick responses, I'm in Australia and yes the time has gone 1 hour backward here but not on the server because the TZ variable was incorrect, I have not changed the time using date command, this would have screwed up things:)

I will set the correct TZ and then check to see the new time if not I will then organize a reboot so the system can pick up a new time.

One more question,

If i refresh cron using 'kill -1 PID', this will refresh the cron daemon right?

I have been working since morning non stop and its nearly midnight here, so I will reply to your post tomorow but please let me know about my other query?

We have a great team here guys, thanks for your help and have a great day.

Cheers
Raf

[James R. Ferguson]

Hi Raf:

The good news is that you say the UTC time is correct. As Dennis noted, verify that with:

# date -u

To stop and restart the 'cron' daemon after fixing your TZ variable, do:

# /sbin/init.d/cron stop
# /sbin/init.d/cron start

The cleanest approach might be to reboot or to stop-and-restart any other long-running applications that have cached a TZ setting during their initialization. In this fashion they will have an opportunity to get the correct one.

Regards!

...JRF...

[Becke]

Thanks James, talking about TZ variable, yes I will do that when I go to work in the morning.

By the way, i was wondering instead of refreshing cron with cron start or stop, if i just simply use 'kill -1 PID' this should also refresh the crod daemon right?

Its midnite now in aus here:) and i have gotta catch up with some sleep as I have been working since morning. I will reply to your post tomorow, thanks everyone

[Becke]

by the way below, i just logged in remotely and ran date -u, so below is the output of date -u as well as date itself

date -u => Thu Mar 29 13:34:46 GMT 2007

date => Thu Mar 29 23:34:50 EET 2007

and obviously I have not changed the TZ variable just yet, I will be setting the correct one tomrow and then will reboot the system, please let me know?

Regards
Raf

[Becke]

Sorry I ran the date commands on the wrong server, that server actually has correct TZ and time is correct on that one, please ignore my previous post, below is the outputs on the machine where TZ is wrong, by the way like i said I have not set the correct TZ just yet, I will be doing it tomorow

date -u => Thu Mar 29 13:38:30 GMT 2007

date => Fri Mar 30 00:38:32 EETDT 2007

above looks ok to me, please let me know
cheers
Raf

[James R. Ferguson]

Hi (again) Raf:

Yes, your UTC (GMT) is correct [ if you run NTP of course, which everybody does :-)) ].

You can see that it is "correct" because it almost matches the post date of your response in this thread.

As far as I know, using 'kill -1' with the 'cron' daemon pid as an argument isn't going to restart 'cron'. This will for sure:

# /sbin/init.d/cron stop
# /sbin/init.d/cron start

Regards!

...JRF...

[Becke]

Thanks james and all, I have learned a lot from all of you in this little conversation:)

I just got called for too many other problems as I'm on-call this week:)not having enough sleep these days.

By the way do you know any good and active AIX forums?? because I'm also working on some AIX servers, I have searched in google and found couple but they are not active at all?

Regards,
Farhan

[A. Clay Stephenson]

Sending a kill -1 (SUGHUP) to the cron daemon will cause cron to reconfigure itself (the crontab command implicitly sends a kill -1 to cron), BUT in this case, it is not sufficient to cause cron to reread a cached tztab entry. For that, as James correctly pointed out, you must actually stop and restart the cron daemon.

What is AIX? (Possibly a badly formed Roman numeral?)

[Becke]

Thanks Stepehen, I will stop and restart the daemon after changing the TZ variable as you guys have mentioned.

By the way apart from HP servers, I have started to work on couple small aix servers as well, AIX is another flavour of UNIX, I thought it may be good to find out any active forums for this as well:), I only get to work sometimes on these servers as they are only legacy servers.

Regards,
Raf

[A. Clay Stephenson]

Thanks for clearing up the mystery of AIX.