Query about the /usr/lib/tztab file

[Nick Sopowski]

Hi, I have been asked to make our systems change from GMT to BST at 20:00 on Saturday 30th March 2002 (i.e at 20:00 move forward to 21:00) instead of the usual setting of 01:00 on Sunday 31st March 2002 .
This is because we are carrying out batch work after 21:00 and didn`t want the system time to change during the run.
I have set the following entry in /usr/lib/tztab (we are in the UK).

0 21 25-31 3 1996-2038 6 BST-1

My question really is , what actually reads this file and deterimes when to change the clock ?. Is the setting picked up when the system is booted - meaning that the changes made by editing the /usr/lib/tztab file will not picked up until the system is rebooted .?

Any ideas ?

[harry d brown jr]

Nick:

http://us-support3.external.hp.com/cki/bin/doc.pl/screen=ckiDisplayDocument?docId=200000058669275


live free or die
harry

[Olav Baadsvik]

Hi,

The file /usr/lib/tztab is read all the time,
or by any command or libc-functions that
inquire about the time.
For instance, if you do a date command you will see that the file is accessed.

do a ls -lu /usr/lib/tztab before and
after you do a date command and you will
see this.

Regards
Olav

[Tracey]

Nick,

There is also a kernel parameter "timezone" that sets the minutes west of greenwich.

Tracey

[Trond Haugen]

Tracey,
There is also a kernel parameter named 'dst' for daylight savings time. But I have been told that nether is rarely used anymore as Olav mentioned.

Regards,
Trond

[Steve Lewis]

I have just been looking into this myself.
The timezone is set on a per-user basis and is not set for the whole system.
So one user can be GMT0BST and another on the same system can be somewhere else in the world with each having their clocks changed at different moments. This is because the system clock is permanently in UTC (= GMT)
You can delay the time change by setting your users environment variable $TZ to GMT0 (=gmtzero without the BST). The time will not change on Sunday morning and they will be stuck in GMT until you reset them all.
If you have a database or other daemons that get the time, then make sure you change their TZ, then bounce that software. Otherwise you will get two interrelated users on different times.
Generally time moving forward will not cause anything to crash, since the system just thinks that nothing has occurred in the jump period, but remember to re-schedule any cron jobs that may try to start at 1:00-1:59, or they will be missed.

[Nick Sopowski]

Thanks all for responding !.

On SUN`s (hope you do not mind me saying that) ,there is a cron entry :-
# The rtc command is run to adjust the real time clock if and when
# daylight savings time changes.
1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1
But on the HP systems I cannot see anything similar ,hence my question.

Something must tell the system to change the time for it to read the tztab file ?.

I checked out the timezone variable from SAM and this is set to 420 minutes west of Greenwich (7 hours) ,which is confusing , seeing that the systems are in the UK !.

Harry - unable to see the link you posted as I am on logged in on the Europe site and the link is on the Americas / Asia Pacific site ,and I cannot login there.

[Olav Baadsvik]

Hi,

Just a comment to your question:
Something must tell the system to change the time for it to read the tztab file?

The answer is that time is not an issue
until you ask what time it is. This you do
by calling a libc-function like localtime
which converts the value fo the UNIX system
clock to your local time.
The entry used in tztab is then determined
by the setting of TZ in the process.

Regards
Olav

[Nick Sopowski]

Olav , thanks but maybe I am not making my concerns clear.
If I call `date` , I know that it reads the /usr/lib/tztab file BUT what I am asking is :- what reads the file at 00:59:59 on Sunday 31st March to then move the clock to 02:00:00 and not 01:00:00 ?.

In my case , I want the clock to change earlier than the standard GMT to BST change (01:00 on Sunday 31st March) and what I am saying is , something must read the tztab file to determine that at 20:00:00 the clock needs to move forward to 21:00:00 on the day specified.

[Frank Slootweg · Accepted solution]

Nick, the 'clock' is *not* changed. The system clock runs on GMT (=UTC), which never changes.

What *does* change is how the time is *presented* (in local time, non-DT versus DST, etc.) and that is what the mentioned libc functions do.

With regard to your tztab modification:

As far as I know you should *not* have to change anything. The existing "GMT0BST" entry should already read:

> # Greenwich Mean Time, British Summer Time
> GMT0BST
...
> 0 2 25-31 3 1996-2038 0 BST-1
>
> 0 1 25-31 10 1996-2038 0 GMT0

So if you have set TZ (see /etc/TIMEZONE) to "GMT0BST", everything should have worked OK since 1996.

Of course if you set TZ to something *else*, i.e. something which is not in tztab, then you will have to *add* a new *entry*, i.e. not just one line, but several lines.

[Nick Sopowski]

Thanks to all who answered - I just needed to get it out of my head that `something` would set the system time to BST ,even though I knew that the system clock always runs at GMT/UCT.
We have never had an issue with the `clocks` going forward in Spring,but,as my customer wanted to make the system time change earlier, on Saturday evening instead of Sunday morning ,it made me wonder how it all worked!.

Interesting point from Steve about the cron jobs - according to the tztab man page , cron knows the time has jumped by an hour and runs the jobs that were scheduled between ,say, 00:59:59 and 01:59:59 .
Hope it is right !.

Thanks again.