Date data-type?

Hi,

I know some of the posters here take a keen interest in the
proposed standards for Cobol.

Do you know if a date data-type has (ever) been proposed; if
yes, what cogent reasons led to its exclusion?

If it's not presently proposed, how exposed does that leave
Cobol, when it's proposed as a viable commercial language?

Ok, the question might not be perfect; make of it what you
think is better .... and answer that!   :-)

Regards

Michael

All previous discussion of a specific "date" data-type have been rejected.
HOWEVER, the draft '08 Standard does have functions to "format" dates (based
 on
locale).  Is this what you looking for?

--
Bill Klein
wmklein <at> ix.netcom.com
"Michael Russell" <Michael.Russell@msn.com> wrote in message
news:N7SdnZu-0s7sR0XZnZ2dnUVZ8qCdnZ2d@pipex.net...
> Hi,
>
> I know some of the posters here take a keen interest in the proposed stand
ards
> for Cobol.
>
> Do you know if a date data-type has (ever) been proposed; if yes, what cog
ent
> reasons led to its exclusion?
>
> If it's not presently proposed, how exposed does that leave Cobol, when it
's
> proposed as a viable commercial language?
>
> Ok, the question might not be perfect; make of it what you think is better
> .... and answer that!   :-)
>
> Regards
>
> Michael

No, William, not really.

I'd expect to see the ability to define a field as a date,
perform date arithmetic; have an "if date" test (like "if
numeric"), too, besides the functions you mention.

I'd also expect this to extend to date-time, with similar
functionality for this.

Heavens, how long have spread-sheets been offering
'date'-types, let alone databases ...

What's the point of Cobol just seemingly ignoring
this obvious possible improvement.

It just acts as a credibility deficit, imo.

Not vitally important, in operational terms, maybe,
but missing a trick here, proponents of Cobol.
(there are some, perhaps?)  :-)

Michael

William M. Klein wrote:
> All previous discussion of a specific "date" data-type have been rejected.
> HOWEVER, the draft '08 Standard does have functions to "format" dates (bas
ed on
> locale).  Is this what you looking for?
>

That's a big reason library based languages have pretty much taken
over.    When someone wants to have a date data type with a library
language, he either downloads it or adds it.   No Codysyl needed.

FYI,
IBM (possibly others) included this as an EXTENSION in their compiler before
Y2K.  This included a lot of "100-year window" option stuff.

Users did NOT find it worth using and although it is still in their compiler
, I
know of almost no users of it.

Most "existing" COBOL shops have routines to do this and very few "new" COBO
L
sites discover a need to "invent" them (is my perception).

--
Bill Klein
wmklein <at> ix.netcom.com
"Michael Russell" <Michael.Russell@msn.com> wrote in message
 news:I76dnd9L95DEuUfZnZ2dnUVZ8sydnZ2d@pi
pex.net...
> No, William, not really.
>
> I'd expect to see the ability to define a field as a date, perform date
> arithmetic; have an "if date" test (like "if numeric"), too, besides the
> functions you mention.
>
> I'd also expect this to extend to date-time, with similar
> functionality for this.
>
> Heavens, how long have spread-sheets been offering 'date'-types, let alone
> databases ...
>
> What's the point of Cobol just seemingly ignoring
> this obvious possible improvement.
>
> It just acts as a credibility deficit, imo.
>
> Not vitally important, in operational terms, maybe,
> but missing a trick here, proponents of Cobol.
> (there are some, perhaps?)  :-)
>
> Michael
>
> William M. Klein wrote: