info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Conversions using the DATE function
169 views
Skip to first unread message
Bob Bridges
May 24, 2021, 2:08:54 PM5/24/21
to
Just out of curiosity, does anyone know what rationale was responsible for
the DATE function claiming it can't convert between a few date formats?
Checking the documentation again; I think it's converting any date format to
Century and Julian. I thought at first there must be some odd programming
reason it won't work, but no, it's easy enough to write my own (as I'm sure
everyone else has found as well). So what's the real reason?
---
Bob Bridges, robhb...@gmail.com, cell 336 382-7313
/* Opportunity is missed by most people because it is dressed in overalls
and looks like work. -Thomas Edison */
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX
the DATE function claiming it can't convert between a few date formats?
Checking the documentation again; I think it's converting any date format to
Century and Julian. I thought at first there must be some odd programming
reason it won't work, but no, it's easy enough to write my own (as I'm sure
everyone else has found as well). So what's the real reason?
---
Bob Bridges, robhb...@gmail.com, cell 336 382-7313
/* Opportunity is missed by most people because it is dressed in overalls
and looks like work. -Thomas Edison */
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX
Paul Gilmartin
May 24, 2021, 3:09:07 PM5/24/21
to
On 2021-05-24, at 12:08:45, Bob Bridges wrote:
>
> Just out of curiosity, does anyone know what rationale was responsible for
> the DATE function claiming it can't convert between a few date formats?
>
> Checking the documentation again; I think it's converting any date format to
> Century and Julian. I thought at first there must be some odd programming
> reason it won't work, but no, it's easy enough to write my own (as I'm sure
> everyone else has found as well). So what's the real reason?
>
o Not ANSI
>
> Just out of curiosity, does anyone know what rationale was responsible for
> the DATE function claiming it can't convert between a few date formats?
>
> Checking the documentation again; I think it's converting any date format to
> Century and Julian. I thought at first there must be some odd programming
> reason it won't work, but no, it's easy enough to write my own (as I'm sure
> everyone else has found as well). So what's the real reason?
>
o Not weo-definwd prre-20th Century.
-- gil
Bill Turner, WB4ALM
May 24, 2021, 5:50:06 PM5/24/21
to
Bob, I suspect that it was just a case of "it just wasn't requested in
the programming specs..."
On date conversions, the TSO based REXX does not allow conversion from
an input date for the CENTURY and JULIAN functions.
Other versions of REXX do support converting from all supported date
formats to any other date format.
Furthermore, the julian function returns a value formatted like yyddd,
which will create other problems as you approach the year xx49/xx50
The JULIAN option should have returned a yyyyddd value, and I suspect
that it remained 2-digit for compatibility reasons. Of course, nobody
thought ahead to prevent another variation of the Y2K type problems. I
would have suggested a different option keyword to get a yyyyddd type value,
had I been asked.
Likewise there is a basic restriction under TSO that a date_format_2
(input value) --MUST-- be in a format that could have been output by the
DATE() function. I also find it absurb that the "DD" portion of the DD
MON YEAR format CANNOT start with a ZERO or Space. (The design
philosophy should have been be user friendly, and they should have
continued Mike Cowlishaw's principal of "least astonishment"...)
Many of the non-mainframe versions of rexx only support the
"day-of-year" as a "julian" like value, and option "D" is used to
request a return value of "ddd" -- just like is provided in the TSO
version of the REXX language...
The maximum return value for CENTURY is 36524 except every fourth
"century leap year" (one that is divisible by both 100 and 400) when the
maximum value returned becomes 36525.
Conveniently, that value be represented as a 16-bit value, so that
function could have operated correctly across all platforms.
It would appear that the date() function was written to match somebodies
exact program specifications, so if conversion was not requested
in the program specs, options just weren't provided.
Any IBM customer, could request additional options, but I'm not willing
to guess how long it might take the REXX development group to actually
supply any newly requested options.
/s/ Bill Turner, wb4alm
the programming specs..."
On date conversions, the TSO based REXX does not allow conversion from
an input date for the CENTURY and JULIAN functions.
Other versions of REXX do support converting from all supported date
formats to any other date format.
Furthermore, the julian function returns a value formatted like yyddd,
which will create other problems as you approach the year xx49/xx50
The JULIAN option should have returned a yyyyddd value, and I suspect
that it remained 2-digit for compatibility reasons. Of course, nobody
thought ahead to prevent another variation of the Y2K type problems. I
would have suggested a different option keyword to get a yyyyddd type value,
had I been asked.
Likewise there is a basic restriction under TSO that a date_format_2
(input value) --MUST-- be in a format that could have been output by the
DATE() function. I also find it absurb that the "DD" portion of the DD
MON YEAR format CANNOT start with a ZERO or Space. (The design
philosophy should have been be user friendly, and they should have
continued Mike Cowlishaw's principal of "least astonishment"...)
Many of the non-mainframe versions of rexx only support the
"day-of-year" as a "julian" like value, and option "D" is used to
request a return value of "ddd" -- just like is provided in the TSO
version of the REXX language...
The maximum return value for CENTURY is 36524 except every fourth
"century leap year" (one that is divisible by both 100 and 400) when the
maximum value returned becomes 36525.
Conveniently, that value be represented as a 16-bit value, so that
function could have operated correctly across all platforms.
It would appear that the date() function was written to match somebodies
exact program specifications, so if conversion was not requested
in the program specs, options just weren't provided.
Any IBM customer, could request additional options, but I'm not willing
to guess how long it might take the REXX development group to actually
supply any newly requested options.
/s/ Bill Turner, wb4alm
Bob Bridges
May 25, 2021, 8:02:37 PM5/25/21
to
Simpler, to my way of thinking, to just do the conversion myself. Takes only two lines of REXX, IIRC. Or is it three?
I'm not sure I can buy the "wasn't requested" hypothesis. At least, I can't imagine writing code like that myself. They went out of their way to make ~exceptions~ -- to say "all the other conversions work, but you can't do these two". And they had to go out of their way, also, to include code that checks to be sure the programmer is adhering to those restrictions. Would've been easier just to include a little extra logic; it isn't like it's complicated.
Or so it seems to me.
/* Easy credit terms available. -Satan */
-----Original Message-----
From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> On Behalf Of Bill Turner, WB4ALM
Sent: Monday, May 24, 2021 17:50
Bob, I suspect that it was just a case of "it just wasn't requested in the programming specs..."
On date conversions, the TSO based REXX does not allow conversion from an input date for the CENTURY and JULIAN functions.
Other versions of REXX do support converting from all supported date formats to any other date format.
...It would appear that the date() function was written to match somebodies exact program specifications, so if conversion was not requested in the program specs, options just weren't provided.
Any IBM customer, could request additional options, but I'm not willing to guess how long it might take the REXX development group to actually supply any newly requested options.
I'm not sure I can buy the "wasn't requested" hypothesis. At least, I can't imagine writing code like that myself. They went out of their way to make ~exceptions~ -- to say "all the other conversions work, but you can't do these two". And they had to go out of their way, also, to include code that checks to be sure the programmer is adhering to those restrictions. Would've been easier just to include a little extra logic; it isn't like it's complicated.
Or so it seems to me.
/* Easy credit terms available. -Satan */
-----Original Message-----
From: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> On Behalf Of Bill Turner, WB4ALM
Sent: Monday, May 24, 2021 17:50
Bob, I suspect that it was just a case of "it just wasn't requested in the programming specs..."
On date conversions, the TSO based REXX does not allow conversion from an input date for the CENTURY and JULIAN functions.
Other versions of REXX do support converting from all supported date formats to any other date format.
Any IBM customer, could request additional options, but I'm not willing to guess how long it might take the REXX development group to actually supply any newly requested options.
--- On 5/24/21 2:08 PM, Bob Bridges wrote:
> Just out of curiosity, does anyone know what rationale was responsible
> for the DATE function claiming it can't convert between a few date formats?
>
> Checking the documentation again; I think it's converting any date
> format to Century and Julian. I thought at first there must be some
> odd programming reason it won't work, but no, it's easy enough to
> write my own (as I'm sure everyone else has found as well). So what's the real reason?
> Just out of curiosity, does anyone know what rationale was responsible
> for the DATE function claiming it can't convert between a few date formats?
>
> Checking the documentation again; I think it's converting any date
> format to Century and Julian. I thought at first there must be some
> odd programming reason it won't work, but no, it's easy enough to
> write my own (as I'm sure everyone else has found as well). So what's the real reason?
Phil Smith III
May 27, 2021, 11:29:48 AM5/27/21
to
Cowlishaw himself says:
The date function originally (e.g., in TRL 1 and in TRL 2) did no
conversions at all; it only took one argument. This was mostly because no
one could agree what to do if an invalid date was supplied. ANSI Rexx did
add conversion options.
No idea why TSO had limited options .. perhaps it was that it only accepted
values that could not fail.
IOW, don't blame him.
...phsiii
The date function originally (e.g., in TRL 1 and in TRL 2) did no
conversions at all; it only took one argument. This was mostly because no
one could agree what to do if an invalid date was supplied. ANSI Rexx did
add conversion options.
No idea why TSO had limited options .. perhaps it was that it only accepted
values that could not fail.
IOW, don't blame him.
...phsiii
Paul Gilmartin
May 27, 2021, 12:22:53 PM5/27/21
to
On 2021-05-27, at 09:29:37, Phil Smith III wrote:
>
> No idea why TSO had limited options .. perhaps it was that it only accepted
> values that could not fail.
>
If it fails it should just fail. E.g.:
>
> No idea why TSO had limited options .. perhaps it was that it only accepted
> values that could not fail.
>
1 +++ say value( 'a + b' )
Error 40 running "/proc/23484/fd/pipe:[93635050]", line 1: Incorrect call to routine
Error 40.26: VALUE argument 1 must be a valid symbol; found "a + b"
But I can think of no case showing the behavior of any function
with input syntactically valid but semantically invalid.
-- gil
Phil Smith III
May 27, 2021, 4:38:25 PM5/27/21
to
Gil wrote:
>If it fails it should just fail. E.g.:
> 1 +++ say value( 'a + b' )
>Error 40 running "/proc/23484/fd/pipe:[93635050]", line 1: Incorrect call
to routine
>Error 40.26: VALUE argument 1 must be a valid symbol; found "a + b"
>But I can think of no case showing the behavior of any function
>with input syntactically valid but semantically invalid.
I sorta had that thought but didn't spend any time on it, and wasn't about
>If it fails it should just fail. E.g.:
> 1 +++ say value( 'a + b' )
>Error 40 running "/proc/23484/fd/pipe:[93635050]", line 1: Incorrect call
to routine
>Error 40.26: VALUE argument 1 must be a valid symbol; found "a + b"
>But I can think of no case showing the behavior of any function
>with input syntactically valid but semantically invalid.
to argue with Mike!
Paul Gilmartin
May 27, 2021, 5:13:08 PM5/27/21
to
On 2021-05-27, at 14:38:13, Phil Smith III wrote:
> ...
exteension. See all the Regina extensions to DATE() a]nd TIME():
https://sourceforge.net/projects/regina-rexx/files/regina-documentation/3.9.1/
-- gil
> ...
>> But I can think of no case showing the behavior of any function
>> with input syntactically valid but semantically invalid.
>
> I sorta had that thought but didn't spend any time on it, and wasn't about
> to argue with Mike!
>
Extensions is exteensions. nd DATE( J ) is a very mainfrme-peculiar
>> with input syntactically valid but semantically invalid.
>
> I sorta had that thought but didn't spend any time on it, and wasn't about
> to argue with Mike!
>
exteension. See all the Regina extensions to DATE() a]nd TIME():
https://sourceforge.net/projects/regina-rexx/files/regina-documentation/3.9.1/
-- gil
Phil Smith III
May 28, 2021, 9:44:42 AM5/28/21
to
Gil wrote:
>Extensions is exteensions. nd DATE( J ) is a very mainfrme-peculiar
>exteension. See all the Regina extensions to DATE() a]nd TIME():
>
https://sourceforge.net/projects/regina-rexx/files/regina-documentation/3.9.
1/
Not tryna be difficult, but I'm not sure what your point is here? (And I
>Extensions is exteensions. nd DATE( J ) is a very mainfrme-peculiar
>exteension. See all the Regina extensions to DATE() a]nd TIME():
>
https://sourceforge.net/projects/regina-rexx/files/regina-documentation/3.9.
1/
don't mean whatever ate your formatting, I can puzzle through that-not your
usual posting style! Maybe some critical part got eaten?)
Paul Gilmartin
May 28, 2021, 12:20:31 PM5/28/21
to
On 2021-05-28, at 07:44:26, Phil Smith III wrote:
>
>> Extensions is exteensions. nd DATE( J ) is a very mainfrme-peculiar
>> exteension. See all the Regina extensions to DATE() a]nd TIME():
>>
> https://sourceforge.net/projects/regina-rexx/files/regina-documentation/3.9.1/
>
> Not tryna be difficult, but I'm not sure what your point is here? (And I
> don't mean whatever ate your formatting, I can puzzle through that-not your
> usual posting style! Maybe some critical part got eaten?)
>
I confess; I ttrimmed aggreessiveely.
>
>> Extensions is exteensions. nd DATE( J ) is a very mainfrme-peculiar
>> exteension. See all the Regina extensions to DATE() a]nd TIME():
>>
> https://sourceforge.net/projects/regina-rexx/files/regina-documentation/3.9.1/
>
> Not tryna be difficult, but I'm not sure what your point is here? (And I
> don't mean whatever ate your formatting, I can puzzle through that-not your
> usual posting style! Maybe some critical part got eaten?)
>
Were you discussing with MFC whether a failurre in a function
can cause a failure in its caller? Does ANSI prohibit itts
doing so as in the example?:
546 $ head f?
==> f1 <==
/* Rexx */
return date( arg( 1 ) )
==> f2 <==
/* Rexx How are invalid function calls reported? */
trace R
call F1 I; say symbol( 'RESULT' ) RESULT
call F1 Z; say symbol( 'RESULT' ) RESULT
547 $ regina F2 Z
3 *-* call F1 I
>L> "I"
*-* say symbol( 'RESULT' ) RESULT
>V> "2021-05-28"
>V> "2021-05-28"
VAR 2021-05-28
4 *-* call F1 Z
>L> "Z"
2 +++ return date( arg( 1 ) )
4 +++ call F1 Z
Error 40 running "/Users/paulgilm/f1", line 2: Incorrect call to routine
Error 40.28: DATE argument 1, option must start with one of "BDEMNOSUWCIT"; found "Z"
*-* say symbol( 'RESULT' ) RESULT
>V> "RESULT"
>V> "RESULT"
LIT RESULT
548 $
-- gil
Phil Smith III
May 28, 2021, 2:53:35 PM5/28/21
to
Gil wrote:
>I confess; I ttrimmed aggreessiveely.
>Were you discussing with MFC whether a failurre in a function
>can cause a failure in its caller? Does ANSI prohibit itts
>doing so as in the example?:
<snip>
>I confess; I ttrimmed aggreessiveely.
>Were you discussing with MFC whether a failurre in a function
>can cause a failure in its caller? Does ANSI prohibit itts
>doing so as in the example?:
I asked him about why date() conversions didn't allow some input formats.
That's all. I think you thought past that (that's as opposed to "overthought
it", which has a negative connotation), and are beyond what I have to offer
on this topic!
0 new messages