Home > Archive > Cobol > September 2005 > INTEGER-OF-DATE
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 2005-08-31, 6:55 pm |
| The help for this function states that for the date input parameter,
the pieces of the day (year, month, day) must be valid including that
the day must be valid for the month/year combo. This seems to me like
INTEGER-OF-DATE is a simple date validation checker.
Question - what happens if you feed it an invalid date? Do you get
back a particular result that indicates an invalid input parm?
Thanks.
-Michael
| |
|
| No, INTEGER-OF-DATE is not a date validation checker.
It returns the integer value of a date, which is extremely useful when
calculating the elapsed number of days between two dates.
The integer value of the date returned by the INTEGER-OF-DATE function
is defined as "the number of days by which the date represented by
argument-1 succeeds December 31, 1600, in the Gregorian calendar."
Using MF Cobol (both OCDS and Server Express) you get a return value of
0 if you pass the function an invalid date. So, in this sense, you
could infact use INTEGER-OF-DATE to tell whether or not you've entered
a valid date. In fact, I've often added a redundant check using the
DATE-OF-INTEGER function to make sure I get back the same value I
started with to absolutely insure that the starting date is indeed
valid.
However, I am not 100% sure whether the result of passing an invalid
date to the INTEGER-OF-DATE function is compiler dependent - you might
want to check into that.
Chris
| |
| HeyBub 2005-08-31, 6:55 pm |
| Michael wrote:
> The help for this function states that for the date input parameter,
> the pieces of the day (year, month, day) must be valid including that
> the day must be valid for the month/year combo. This seems to me like
> INTEGER-OF-DATE is a simple date validation checker.
No, the purpose is to return the number of days since December 31, 1600. If
the compiler developers, in their infinite wisdom, wanted to provide a
date-validation checker, they would have found a less-convoluted method.
For extra credit: How many days are there between August 4, 1945 and today?
>
> Question - what happens if you feed it an invalid date? Do you get
> back a particular result that indicates an invalid input parm?
I don't know. I've always been careful to pass the function a valid date.
For an invalid date, the function may return zero - although how you could
tell this meant "invalid" is a mystery, or do the same thing when you
attempt to divide by zero. For all I know, the routine may carry off the
more preferable bits on its shoulder. Sorry.
| |
| William M. Klein 2005-08-31, 6:55 pm |
| The results are totally UNDEFINED (in Standard COBOL) when an invalid argument
is passed.
Some implementors have already implemented the TEST-DATE-YYYYMMDD and
TEST-DAY-YYYYDDD intrinsic functions which allow one to not only determine if a
date is valid, but if it isn't to figure out what part is wrong. This is part
of the '02 ISO COBOL Standard (as is the EC- exception to detect invalid
arguments).
As far as INTEGER-of-DATE/DAY, the two MOST common results of invalid arguments
in current implementations are:
- return 0
- abnormal termination of entire program
However, I think I heard of one compiler/run-time that for
"20050230"
actually returned the value that would be correct for
"20050302"
Bottom-Line:
You either must TEST your argument first, or you need to some-how KNOW it is
correct.
--
Bill Klein
wmklein <at> ix.netcom.com
"Michael" <dragonmsw@yahoo.com> wrote in message
news:1125499576.703359.316050@g49g2000cwa.googlegroups.com...
> The help for this function states that for the date input parameter,
> the pieces of the day (year, month, day) must be valid including that
> the day must be valid for the month/year combo. This seems to me like
> INTEGER-OF-DATE is a simple date validation checker.
>
> Question - what happens if you feed it an invalid date? Do you get
> back a particular result that indicates an invalid input parm?
>
> Thanks.
>
> -Michael
>
| |
| Rick Smith 2005-08-31, 6:55 pm |
| > "Michael" <dragonmsw@yahoo.com> wrote in message
> news:1125499576.703359.316050@g49g2000cwa.googlegroups.com...
[snip]
[snip]
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:XPlRe.34721$kM5.31677@fe01.news.easynews.com...[color=darkred]
> The results are totally UNDEFINED (in Standard COBOL) when an invalid
argument
> is passed.
Well ... technically the result is unpredictable and arises
from "3.3 A conforming run unit" which states, in part,
"The processing of a conforming run unit is predictable
only to the extent defined in standard COBOL. The
results of violating the formats or rules of standard
COBOL are undefined unless otherwise specified in
this International Standard." The INTEGER-OF-DATE
function has no rule concerning an invalid date; therefore,
no rule to violate. This leaves unpredictable.
| |
| William M. Klein 2005-08-31, 6:55 pm |
| Well, actually, no - it is undefined.
See page A-28 of the Intrinsic Functions Amendment (to the '85 Standard) which
states, in part
"The rules for a function may place constraints on the permissible values for
arguments in order to permit meaningful determination of the function's value.
If, at the time a function is referenced, the arguments specified for that
reference do not have values within the permissible range, the returned value
for the function is underlined."
(Of course this changed slightly in the '02 Standard when an exception for this
condition was introduced).
--
Bill Klein
wmklein <at> ix.netcom.com
"Rick Smith" <ricksmith@mfi.net> wrote in message
news:11hc5nejm13tmfd@corp.supernews.com...
> [snip]
> [snip]
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:XPlRe.34721$kM5.31677@fe01.news.easynews.com...
> argument
>
> Well ... technically the result is unpredictable and arises
> from "3.3 A conforming run unit" which states, in part,
> "The processing of a conforming run unit is predictable
> only to the extent defined in standard COBOL. The
> results of violating the formats or rules of standard
> COBOL are undefined unless otherwise specified in
> this International Standard." The INTEGER-OF-DATE
> function has no rule concerning an invalid date; therefore,
> no rule to violate. This leaves unpredictable.
>
>
>
| |
| Chuck Stevens 2005-08-31, 6:55 pm |
|
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:qapRe.33485$8n3.23130@fe05.news.easynews.com...
> Well, actually, no - it is undefined.
>
> See page A-28 of the Intrinsic Functions Amendment (to the '85 Standard)
which
> states, in part
>
> "The rules for a function may place constraints on the permissible values
for
> arguments in order to permit meaningful determination of the function's
value.
> If, at the time a function is referenced, the arguments specified for that
> reference do not have values within the permissible range, the returned
value
> for the function is underlined."
Thereby rendering the returned value ... what ... edited-numeric? I didn't
know the COBOL character set provided for the underlining of, say,
usage-binary results from intrinsic functions! Does the underlining
somehow emphasize its undefined content? ;-D
Don't you just love automated spell-checkers, Bill? ;-)
-Chuck Stevens
| |
| William M. Klein 2005-08-31, 6:55 pm |
| Actually, the real problem is/was that the '85 Standard and amendments are in
"semi-graphic" format (in their digital version) and when I try and
cut-and-paste, it can come up with some real winners (like this). <G>
Oh, well, I think the point was clear.
P.S. Don't ask me what the "real-world" difference is between explicitly
undefined and implicitly undefined and unpredictable - as far as the COBOL
Standard goes.
--
Bill Klein
wmklein <at> ix.netcom.com
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:df57h3$1trs$1@si05.rsvl.unisys.com...
>
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:qapRe.33485$8n3.23130@fe05.news.easynews.com...
>
> which
> for
> value.
> value
>
> Thereby rendering the returned value ... what ... edited-numeric? I didn't
> know the COBOL character set provided for the underlining of, say,
> usage-binary results from intrinsic functions! Does the underlining
> somehow emphasize its undefined content? ;-D
>
> Don't you just love automated spell-checkers, Bill? ;-)
>
> -Chuck Stevens
>
>
| |
| Rick Smith 2005-08-31, 6:55 pm |
| > "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:11hc5nejm13tmfd@corp.supernews.com...
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:qapRe.33485$8n3.23130@fe05.news.easynews.com...[color=darkred]
> Well, actually, no - it is undefined.
>
> See page A-28 of the Intrinsic Functions Amendment (to the '85 Standard)
which
> states, in part
>
> "The rules for a function may place constraints on the permissible values
for
> arguments in order to permit meaningful determination of the function's
value.
> If, at the time a function is referenced, the arguments specified for that
> reference do not have values within the permissible range, the returned
value
> for the function is underlined."
>
> (Of course this changed slightly in the '02 Standard when an exception for
this
> condition was introduced).
The last explains it. I was referring to the FDIS for 2002
which does not use "undefined"; but, instead, states, in part,
"If the EC-ARGUMENT-FUNCTION exception condition
is set to exist and checking for EC-ARGUMENT-FUNCTION
is not enabled, the implementor defines the result of the
function reference." Thus, it seems to me now, there was a change
from undefined (1985 as amended) to unpredictable (2002).
| |
| Rick Smith 2005-08-31, 6:55 pm |
|
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:hopRe.35873$w74.35824@fe03.news.easynews.com...
[snip]
> P.S. Don't ask me what the "real-world" difference is between explicitly
> undefined and implicitly undefined and unpredictable - as far as the COBOL
> Standard goes.
The 2002 standard, as I understand it, does not deal
with implicitly undefined. I think the trio is: explicitly
undefined, expressly undefined, and unpredictable.
The items of the "Undefined elements list" are explicitly
undefined, violations of formats and rules (and maybe
other conditions) are expressly undefined, and that
not defined by the standard is unpredictable. But that
is just my understanding.
| |
| Arnold Trembley 2005-09-01, 3:55 am |
|
HeyBub wrote:
> (snip)
> For extra credit: How many days are there between August 4, 1945 and today?
2005-09-01 = 732,190
1945-08-04 = 710,247
21,943 days
But since "today" was 2005-08-31 for you, I suppose you want 21,942
days. And if your interpretation of "between" excludes the ending
date, perhaps you wanted 21,941 days...
--
http://arnold.trembley.home.att.net/
| |
| Walter Murray 2005-09-01, 6:55 pm |
| "William M. Klein" <wmklein@nospam.netcom.com> wrote:
> Well, actually, no - it is undefined.
> See page A-28 of the Intrinsic Functions Amendment (to the '85 Standard)
which
> states, in part
> "The rules for a function may place constraints on the permissible values
for
> arguments in order to permit meaningful determination of the function's
value.
> If, at the time a function is referenced, the arguments specified for that
> reference do not have values within the permissible range, the returned
value
> for the function is underlined."
Leaving aside the typo in Bill's response, I think that this rule was
superseded by the Correction Amendment, ANSI X3.23b-1993, page B-25. The
wording "the returned value for the function is undefined" was changed to
"then the result of such a reference is undefined".
The earlier rule gave a conforming implementation the right to return an
unpredictable value. The amended rule actually gives the implementation
permission to abort the program.
Walter
Walter J. Murray
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
|
|
|
|
|