At this risk of Dilberting the list by arguing until everyone else just
gives up in exasperation, or getting myself flamed, or starting a
mailstorm (maybe too late on that one: 20+ postings in this thread so
far), I would like to respond to the other contributors' thoughts. I
LOVE COBOL, and have been following the ANSI 97 initiative as well as
YEAR2000 mailing list since before Bob Dole was running for nomination,
so I have had occasion to consider this issue.

Marnix Van Achter wrote:
>>I don't see any reason to create something like HPYEAR4. What I think
>>that would be a good thing to have is a variable for the complete date
>>in the format YYYYMMDD (e.g. 19961120).
>
>>Something else that I was looking for recently also might be interesting
>>to have, and that is a variable for the calendar week.

I see the usefulness of a calendar week of the year; Julian day could be
useful as well.

Currently, we only have the group variables as strings whose names end
with F (with apologies to Carl Hughes; I appreciate the elegance of your
suggestion, but "F stands for formatted", and that means a string).
CCYYMMDD is in fact a departure from this design philosophy; although if
HP wants to do something unprecedented, handing us the full date in one
variable does seem to have gotten a lot of votes. David Greer does have
a point: the four digit year is more likely to be used as is than the
century would be alone; and in those rare cases when just the century is
needed, it could be trimmed out just as the weekday abbreviation can
(only) be had by trimming it from HPTIMEF. But note that while the
century is properly part of the year, group and account are part of a
path or file specification, and we have to build that string; likewise
for HH:MM. Which leads us to a MAJOR question: If we are building long
years with HPCENTURY and HPYEAR, what will HPYEAR equal in 200#? Will it
have the leading zero(s) or not? To do so would be welcome, but also it
would be inconsistent with HPMONTH and HPDAY, and probably an
enhancement.

On the other hand,

Don Harrington wrote:
>If a century variable is _really_ needed,
>one could be extracted from the four-digit year.

And all numeric time elements could be extracted from 19961021115648,
but aren't you glad that you don't have to?

Tony Furnivall wrote:
>let's not fall into the situation where we are mired in the
>"Backward Compatibility" problem. Years are (presently!) defined with 4
>digits. It seems to me that we should bite the proverbial bullet...

Too late for that. HP has distinguished itself by letting users live in
the past while using the latest technology. We move from the known to
the unknown, and abandoning the current design philosophy (and note well
that there does seem to be one here) would be tragic. Is there some
compatibility that you regret, Tony? Is anyone out their 'upgrading'
their OS or language to change what is returned by a currently existing
date feature? Or are they adding an new element? ANSI 97 COBOL will have
a new reserved word for long date, and will leave "ACCEPT whathaveyou
FROM DATE" alone. I'll leave it to Gopi to tally the votes.

Steve Dirickson wrote:
Bingo. A "year object" is no more sufficiently/correctly identified by a
2-digit value than an "address object" is by a number and street. HPYEAR
should contain the correct year value (which is not limited to 4 digits,
by the way), and users who need to extract the modulo-century (or
modulo-millenium, or whatever) part of it can use 'rht()'. Though it
would probably be handy to predefine an HPSomething variable to provide
the two rightmost digits of the multi-digit year value, since so much
existing software uses that value.

HPVars are not objects. And we are a little premature in anticipating a
YEAR10,000 problem; I expect that their development tools might be
sufficiently robust when that time comes, if we haven't already
converted to star dates. Agreed, it is handy to have an HPVar to provide
the short year; so much software does use that, that dinking with it
undervalues that legacy (does anyone else outside of IT use legacy as a
pejorative?). John Korb says it so well that I can only commend you to
his posting.

Ken Sletten wrote:
(1)  The HPYYYY var name is the same length as HPYEAR;
easily replaceable if somehow you want to maintain source text
column alignment or whatever.
(2)  HPYYYY sorts right after HPYEAR when doing a
SHOWVAR.  HPLONGYEAR is > one screen page away.

The only thing they have in common are that they begin with HP. Nothing
else allows us to group them. The argument from grouping has no
precedent in variable names. Following are HP time variables, a cut &
paste from a SHOWVAR HP@, with elision of non-time variable. Note that
they are of two types: two variable length strings which end with F
(SHOWVAR HP@F lists five on our 3K); and six elements or elementary
items that like the atom are not normally reduced further (well, I did
once have to parse decade).

HPDATE = 21
HPDATEF = THU, NOV 21, 1996
HPDAY = 5
...
HPHOUR = 11
...
HPMINUTE = 25
HPMONTH = 11
...
HPTIMEF = 11:25 AM
...
HPYEAR = 96

The consensus seems to be to give us the long year with a short name. A
few want a full date spec as well. A couple want the HPYEAR to be the
long year, but several posters noted that this would trash their current
work. I still find long and short intuitively obvious ways of referring
to year, so I still like HPLONGYEAR best, but that does not seem to be
the consensus. I could live with HPYEAR4. Reviewing the vars, they are
composed of real words or abbreviations that are standard within the 3K
community, so I suggest that HPCCYY or HPYYYY would stick out like a
sore thumb.

SET ABSURDITY ON
Here's half a thought: John Korb's tips are too easy to use. Just give
us HPCentury, and let those who want something else roll their own from
their system logon UDC: SETVAR VDATE !HPCENTURY!HPYEAR!HPMONTH!HPDAY...
SET ABSURDITY OFF
SET TIP ON
But this sort has to be built one at a time; take time for instance:
IF LEN("!HPHOUR")=1
   SETVAR VTIME "0"+"!HPHOUR"
ELSE
   SETVAR VTIME "!HPHOUR"
ENDIF
IF LEN("!HPMINUTE")=1
   SETVAR VTIME VTIME+"0"+"!HPMINUTE"
ELSE
   SETVAR VTIME VTIME+"!HPMINUTE"
ENDIF
etc.

>----------
>From:  M Gopalakrishnan[SMTP:[log in to unmask]]
>Sent:  Wednesday, November 20, 1996 10:28 AM
>To:    [log in to unmask]
>Subject:       Proposal for new HPCENTURY CI variable
>
>Hi
>
>We are currently in the process of adding new CENTURY variable for
>MPE/iX.
>
>Proposed HPCENTURY CI variable would return the century component
>(first two digit of the current year) corresponding to the HPYEAR
>CI variable. For example,
>
>  In 1997,   HPYEAR = 97 and HPCENTURY = 19
>     2000,   HPYEAR = 00 and HPCENTURY = 20
>     2001,   HPYEAR = 01 and HPCENTURY = 20 and so on.
>
>Hence, we would be having HPCENTURY and HPYEAR variables to get the Year.
>
>Question : Do you need (how important it is) to  have a new CI variable for
>           four-digit year, having 1997 for Year 1997, 2000 for Year 2000,
>           and so on?. If you need, what would be the better name for the
>           variable? (one suggestion is : HPYEAR4).
>
>I am working with Kishore ([log in to unmask]) on the new date intrinsics
>proposal. The proposal will be available to this newgroup/3000-L for
>discussion in the week starting 26 Nov 96.
>
>Thanks and regards,
>
>Gopi ([log in to unmask])
>CSY R&D India, Bangalore.
>