Subject: | |
From: | |
Reply To: | |
Date: | Tue, 29 Dec 1998 16:37:07 -0800 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
Gavin after me:
>> As to Dictionary/3000 not being Y2K compliant: Yikes !!!....
>> .... sure enough: DATE-CREATE and DATE-CHANGE are
>> pervasive in almost all the datasets in the DICT database;
>> they are both YYMMDD X6.... oops....
> Does anyone really care?
Quite possibly not.
> I assume these fields simply store the
> date that a dictionary entry was created/modified?
I think that is the case; I have asked HP to comment.
> Sounds completely Y2K compliant to me.
Well..... that may depend on how some organizations define
Y2K compliant. If Gavin's assumption (same as mine) is
correct, then DICT/3000 is Y2K compliant from one technical
point of view. But from the management and political perspective
(which organizations like the Federal Government tend to adopt
from time to time), it might be difficult to "sell" a product as fully
Y2K compliant as long as it stores dates as YYMMDD X6.... I
vaguely recall seeing an internal checklist where someone had
come up with a blanket question along the lines of "Are all dates
stored in a manner so as to include century information ?". A
"no" to this question would likely lead to more questions and long
explanations to the Y2K police... but; yeah: If none of the DICT
utilities care about Y2K rollover in these two fields, it should be
possible to convince the checklist beancounters that it doesn't
matter....
disclaimer: I had nothing to do with generating that checklist...
:-) ,
Ken Sletten
|
|
|