Hi,

wow - I just returned from vacation and saw that there is long thread on the 
PCA mailing list! This hasn’t happened for years :)

While I don’t plan to put time in the development of PCA anymore, this sounded 
interesting enough to take a short look. Turns out that it took 22 years for 
this Y2K issue to show up.

A little background: 

SUN decided to use 2-digit years in the patch release date column in 
patchdiag.xref, which was a bad idea. Plus, there are a handful of patches with 
an empty release date field. That’s why I used a standard date (Jan/01/71) in 
PCA to fill in the missing data, which is used to calculate the age of the 
patch.

PCA uses perl’s timelocal() function, which has an interesting way to deal with 
2-digit years. From the man page:

"Years in the range 0..99 are interpreted as shorthand for years in the rolling 
``current century,'' defined as 50 years on either side of the current year. 
Thus, today, in 1999, 0 would refer to 2000, and 45 to 2045, but 55 would refer 
to 1955. Twenty years from now, 55 would instead refer to 2055. This is messy, 
but matches the way people currently think about two digit dates. Whenever 
possible, use an absolute four digit year instead.“

So for a long time, 71 was interpreted as 1971. But in 2022, 2071 is actually 
closer to now than 1971, so suddenly timelocal() switches from 1971 to 2071.

Thanks to Marcel, who already figured this out and provided a workaround. As 
the fix is simple enough, I decided to push a new version of PCA. I’m using 
Jan/01/00 as the default date now, which should give us enough time until the 
last installation of Solaris 10 is gone… ;)

Martin.


> Am 16.08.2022 um 17:47 schrieb Ken Harford <kharf...@comcast.net>:
> 
> Hi All,
> 
> This already may have been addressed but I am new here
> 
> When running  "pca -l all” on Solaris 10 I get the following error:
> 
> Using /var/tmp/patchdiag.xref from Aug/15/22
> Cannot handle date (0, 0, 0, 01, 0, 2071) at ./pca line 2511
> 
> Has anybody else run into this? And if so is there a workaround?
> 
> Thanks
> Ken


Reply via email to