editing the tztab file manually

[MBirk]

In preparation for the new changes to Standard and Daylight Times, I used the vi editor to modify the /usr/lib/tztab file after making a copy of it called tztab.old. Here's the only "diff" between the 2 files:

43c43
< 0 3 1-7 4 1987-2038 0 EDT4
---
> 0 3 8-14 3 2007-2038 0 EDT4
46c46
< 0 1 25-31 10 1975-2038 0 EST5
---
> 0 1 1-7 11 2007-2038 0 EST5

Yet when I made the change, the clocks instantly jumped an hour ahead and went from EST to EDT. I then made the mistake of using the "date" command to "run time backwards." That made the time correct, but it is still in EDT instead of EST.

I then decided to put the old tztab file back in place and on one system it worked instantly, reverting back to EST. However the time stayed the same so I used the "date" command to set the clock forward and all is well with that system. All other systems, however, remain unchanged, even when I put the old tztab back in place.

Any suggestions?

(Note: I was unaware of patch PHCO_34668 at the time.)

[James R. Ferguson]

Hi Mark:

You bungeled your editting; you need:

0 3 1-7 4 1987-2006 0 EDT4
0 3 8-14 3 2007-2038 0 EDT4

0 1 25-31 10 1975-2006 0 EST5
0 1 1-7 11 2007-2038 0 EST5

You then made a worse mess by running time backwards. I hope your server isn't a production database one.

Next, you have no record of you changes in the Installed Product Database ('/var/adm/sw') because you manually updated the 'tztab' instead of applying the patch.

Do yourself a favor. Stop any databases. Set your server time to UCT using 'date -u'. Apply the correct patch. Reboot your server. While application of the patch does not a priori require a reboot, doing so means that all processes have an opportunity to re-read/re-cache the updated 'tztab' rules via the libC routines.

Regards!

...JRF...

[Bill Hassell]

It's really important NEVER to change the time of day unless you stop your applications and then set the time using GMT (UTC or Zulu) with date -u. The reason is that the date command is being filtered by TZ which looks at the tztab file. If you munge the values in tztab file then the date command as well as *all* other applications that work with time will be affected.

The patch is trivial -- it simply replaces the tztab file. This file is regularly replaced as governments change local timezone rules. You can simply extract the file from the patch (depot files are just tar archives) or run swinstall.

[MBirk]

James and Bill,

I'd like to thank you both for your help.

I was going through some other threads concerning this same issue and found references to the following patches:

PHCO_34669 11.23
PHCO_34668 11.11
PHCO_27258 11.0

Later there is a reference to patch PHCO_34673. Is this for 11.0 only or for all versions of the O/S? If it is for 11.0 only, is the patch listed for 11.11 still valid for that O/S version?

[James R. Ferguson]

HI:

In reality, any of the patches for will work. The DST patch delivers an updated '/usr/lib/tztab' file. The value of using the appropirate patch for the appropriate operating system version is that 'swinstall' records the patch in its Installed Product Directory thus tracking your change and performing the correct setting for file permissions and ownership.

The current patches can be noted here:

http://h10072.www1.hp.com/dst/

Click on the HP Customer Notice Document ID: c00832124 .

Regards!

...JRF...

[A. Clay Stephenson]

You can almost certainly load the 11.0 version of the patch on 11.11 though you would probably have to enable the "allow installation of incompatible software" swinstall option. But why bother?

PHCO_34673 supercedes PHCO_27528.

I would load the patch that is appropriate to your OS. That will make future patching easier. The exception to this is if you are running 10.20; in that case, copy the tztab from one of the newer boxes to the 10.20 tztab. Tztab is simply a text file so you could make the changes yourself but patching is the better way as it keeps the installed software database current and consistant.

[MBirk]

I installed the appropriate patches for the tztab changes:

PHCO_34673 for 11.0
PHCO_34668 for 11.11

The new tztab now appears and swlist shows the patch.

However, I'm having an issue with swinstall on two of the servers. Couldn't I just rcp or ftp the new tztab file from one of the other servers to the servers I'm having a problem with?

I'm not concerned about whether or not the patch shows up in swlist, only that it works.

[A. Clay Stephenson]

Yes, you can copy the tztab to other systems but you aren't thinking very deeply. It's not so much that the patch won't be displayed in swlist but rather that future patches will expect one cksum for tztab and will see another value. At the very least, you will get swinstall warnings. Moreover, future patches might depend upon the tztab patch (or its successors) being on the system and fail. This is a trivially easy patch to install and if you are having problems installing it on anything other than 10.20 boxes then it points to deeper problems with your installed software database. Perhaps because you have already used your "cowboy" patch deployment technique in the past?

[James R. Ferguson]

Hi (again) Mark:

> I'm having an issue with swinstall on two of the servers. Couldn't I just rcp or ftp the new tztab file from one of the other servers to the servers I'm having a problem with? I'm not concerned about whether or not the patch shows up in swlist, only that it works.

In that case, then yes.

Regards!

...JRF...

[MBirk]

Clay:

Cowboy?

As I stated in my first entry, I was unaware that there was a patch for this issue. I was merely told that the tztab needed to be modified, so that's what I did. You said much the same in one of your posts:

"Tztab is simply a text file so you could make the changes yourself..."

I'd like thank everyone for their input.

Consider this thread closed.

[MBirk]

Issue solved.