Home > Archive > Cobol > August 2006 > Date data-type?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Michael Russell 2006-08-08, 6:55 pm |
| 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
| |
| William M. Klein 2006-08-08, 6:55 pm |
| 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 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
| |
| Michael Russell 2006-08-09, 6:55 pm |
| 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 (based on
> locale). Is this what you looking for?
>
| |
| Howard Brazee 2006-08-09, 6:55 pm |
| 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.
| |
| William M. Klein 2006-08-09, 6:55 pm |
| 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" COBOL
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...[color=darkred]
> 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:
|
|
|
|
|