Showing results for 
Search instead for 
Did you mean: 

DST Patch for unix 4.0F DUV40FB18AS0007 PK1 (??)patch level


DST Patch for unix 4.0F DUV40FB18AS0007 PK1 (??)patch level

Hi All,

You might have got these kind of query. This is bit diffrent. we have old tru64 box running "Digital UNIX V4.0F (Rev. 1229); Wed Jul 9 19:15:20 PDT 2003" with DUV40FB18AS0007-20020102 kit installed that is been up from 703 day. Now the one on the hp website they have link for "HP Tru64 UNIX V4.0F PK8 ". our I think pk1..question the same I can apply here without going for PK8? if not is there any easy solution for me?

The prerequisite says required is PK8.

Thanks in Advance.
Archunan Muthiah
Honored Contributor

Re: DST Patch for unix 4.0F DUV40FB18AS0007 PK1 (??)patch level


If there is no problem after installing pk7(especially with NHD3 patches), then you can go ahead download pk8 and install.

God is Artist, we are all just brushes
Martin Moore

Re: DST Patch for unix 4.0F DUV40FB18AS0007 PK1 (??)patch level

There is no DST patch available for V4.0F PK7 or earlier, because those patch levels are out of support. The only V4.0F patch is for PK8, and you can't install a PK8 patch on PK7; dupatch won't let it happen.

Your choices are to:

1. Go to PK8 (a good idea in any case) and then install the available DST patch.

2. Make the necessary changes manually, i.e., edit the timezone source files and recompile the timezone definitions with "zic". I believe there are other threads here with details on this.

I work for HP
A quick resolution to technical issues for your HP Enterprise products is just a click away HP Support Center Knowledge-base
See Self Help Post for more details


Re: DST Patch for unix 4.0F DUV40FB18AS0007 PK1 (??)patch level

Archunan & Martin,

THANKS for the time. I am not in support of doing pk8 because We can'nt afford to fail on this one. Also I am not good at compilation stuff. is it possible that I can change the date & time manually on the system. since this box is going retire in another 6 months? is that good choice?

many many thanks

Honored Contributor

Re: DST Patch for unix 4.0F DUV40FB18AS0007 PK1 (??)patch level

The calculation of time in all Unixes is fundamentally based on GMT/UTC time (actually known as "Unix time_t", number of seconds since January 1st 1970, 00:00 GMT). If your time zone definitions have been correct until now, your system clock is running in correct UTC time and transparently converting to/from your local timezone whenever you need local time or specify time in terms of local time.

This makes time calculations much simpler: because the GMT/UTC time does not use DST, the timescale is continuous and each moment in time can be uniquely identified, even when the local time "falls back" in DST->Standard transition and one hour is "doubled" according to local time. When a file is created during that doubled hour, the system can still tell you whether the file was created during the DST or the Standard "version" of the hour.

All the timestamps in the filesystem are internally stored in Unix time_t format, for example.

If you change the system's idea of local time according to the new rules without changing the timezone information, you'll skew the system's idea of GMT/UTC time by one hour. When the old rules say it's time to transition to DST, you need to change the system time again.

After this, the system's idea of UTC time will again agree with the true UTC. You'll also have introduced *two* breaks to the system's UTC timescale, which normally has *never* any breaks at all. One of the breaks will be "spring forward" and the other "fall back" type. So there will be non-unique timestamps and files created up to one hour "in the future".

So, if you cannot get official patches for your OS version, I'd recommend you edit the timezone definition and use the "zic" command to make the changes available to the system.
This is why the "zic" command is included into the OS: so you won't be dependent on the vendor patches if the DST rules change.

In some countries, the government used to decide the times of DST transitions independently for each year. Unix admins in these countries have dealt with that, by editing the timezone definitions whenever necessary.