OK, I've read a dozen or more posts on this topic expecting someone to
state what [IMHO] is the real issue here, but after reading Stan's three
replies and still coming up empty, let me state what I thought should
have been obvious here...

The $64K question should be:  What does HPYEAR return in 2000?  Does it
give you 0?  00?  100?  What value?

We have HPYEAR today.  The only things [immediately] at risk of being
"broken" are comparisons (00<99, but 2000>1999).  So I re-iterate, what
will the *existing* variables return?  zero?  100?  200?  Returning 100
would "fix" comparison instances (treated numerically) which is
essentially what HP has done with CALENDAR date formats; you don't
return the "year-of-century" as zero in 2000, you return it as "100".

If you want a new four-digit year, fine.  I don't care if you make one
or not (there were replies to get a four-digit year; I really liked the
CI.PUB.SYS access date example).  If you make one I don't care what you
call it.  If you make one and decide on a name I don't care how you want
to format it (well, that's not completely true, but...).  We're talking
about *new* functionality.  This is a *moot* point to backward
compatibility issues.  I think the alleged posting by Tony Furnival on
forgetting backward compatibility was a forgery , I'll have to check the
tcp logs to verify that origin address :-)

You are "micro-managing" the *new* functionality of a century/4-digit
year variable and ignoring what *current* stuff does [HPYEAR].  Let's
not bicker with CSY/ISO over variable names for new stuff, we should be
thankful to get it (though suggestions for names are welcomed, I'm sure;
though I don't think they merit a soapbox debate).  The answer I want is
what happens to existing functionality.  If HPYEAR is documented
somewhere as "already decided to be foo-blah" I retract my response :-)
but I think the issue of zero vs 100 (vs 200) is of primary concern.

But on the "micro-management" issue... I'd much prefer ONE variable with
all clock information you could substring from as opposed to the growing
number of possible individual date/time/etc variables.

Jeff Kell <[log in to unmask]>