Julian date to Gregorian REXX routine
Gerard S.
|Subject: Re: LISTDSI
|
|On 30 Mar 2000 at 08:42, Baskaran Subramaniam
|
|> We have to convert the Julian date format of SYSCREATE, SYSREFDATE,
|> SYSEXDATE in the LISTDSI to Gregorian date format.
|> Is there any option in LISTDSI available or any REXX function
|> available to convert from one format to another.
|
|In recent levels of TSO/E (2.5 and up, I believe), the DATE function can
|perform some conversions, although I seem to remember that it won't
|convert julian to gregorian. Here is a simple, table-less function,
|extracted from the WHOAMI exec in file 183 of the CBT tape:
|
| /***************************************************************/
| /* JULIAN-TO-GREGORIAN CONVERSION ROUTINE */
| /* GDATE=GREGORIAN(1992134) */
| /* RETURNS "YYYY/MM/DD" */
| /***************************************************************/
| GREGORIAN: PROCEDURE
| YYYY=LEFT(ARG(1),LENGTH(ARG(1))-3)
| DDD=RIGHT(ARG(1),3)
| T=(YYYY//4=0)
| DD=DDD; IF DD>(59+T) THEN DD=DD+2-T
| MM=((DD+91)*100)%3055
| DD=DD+91-(MM*3055)%100
| RETURN YYYY'/'RIGHT(MM-2,2,'0')'/'RIGHT(DD,2,'0')
|
| Gilbert Saint-flour
_______________________________________________________
The above routine fails to take into account the leap-year century rule,
it fails for 1700, 1800, 1900, 2100, 2200, 2300 and others.
Gerard S.
Gilbert Saint-flour
"Gerard S." <ger...@prairietech.net> said:
> | GREGORIAN: PROCEDURE
> | YYYY=LEFT(ARG(1),LENGTH(ARG(1))-3)
> | DDD=RIGHT(ARG(1),3)
> | T=(YYYY//4=0)
> | DD=DDD; IF DD>(59+T) THEN DD=DD+2-T
> | MM=((DD+91)*100)%3055
> | DD=DD+91-(MM*3055)%100
> | RETURN YYYY'/'RIGHT(MM-2,2,'0')'/'RIGHT(DD,2,'0')
>The above routine fails to take into account the leap-year century rule,
>it fails for 1700, 1800, 1900, 2100, 2200, 2300 and others.
You're right, and I believe it's intentional because it doesn't matter:
computers weren't invented in 1900 and we'll all be dead in 2100.
Gilbert Saint-flour
http://members.home.net/gsf/
Gilbert Saint-flour
"Gerard S." <ger...@prairietech.net> said:
>|>The above routine fails to take into account the leap-year century rule,
>|>it fails for 1700, 1800, 1900, 2100, 2200, 2300 and others.
>|
>|You're right, and I believe it's intentional because it doesn't matter:
>|computers weren't invented in 1900 and we'll all be dead in 2100.
>Of course, it would be better yet if the bug was fixed. I don't want to
>believe that the bug was intentional, since I try to write boilerplate
>subroutines, especially routines posted, or stored in a shared database
>such as the CBT.
It's not a bug, but a feature. When I wrote this REXX routine 7 years ago
(by converting an existing piece of code that was written in another
language), I purposely left the 100-year rule out. The routine was
intended to be used to convert system dates and it'll work until 2099
which is pretty good, I believe.
I posted this routine here in response to someone who had a problem with
dates found in F1-DSCBs, which didn't exist prior to 1965 (or so). The
fact that the date conversion won't work in 2100 doesn't worry me much;
chances that it'll be still in use in 100 years are pretty slim.
Gilbert Saint-flour
http://members.home.net/gsf/
Frank Clarke
wrote:
>... and we'll all be dead in 2100.
That's awfully pessimistic, isn't it?
Frank Clarke
Member of the REXX Language Association
Join us at http://www.rexxla.org
Gerard S.
|In <xfVE4.265$983....@newsfeed.slurp.net>, on 30 Mar 2000 at 21:57,
|"Gerard S." <ger...@prairietech.net> said:
|
|> | GREGORIAN: PROCEDURE
|> | YYYY=LEFT(ARG(1),LENGTH(ARG(1))-3)
|> | DDD=RIGHT(ARG(1),3)
|> | T=(YYYY//4=0)
|> | DD=DDD; IF DD>(59+T) THEN DD=DD+2-T
|> | MM=((DD+91)*100)%3055
|> | DD=DD+91-(MM*3055)%100
|> | RETURN YYYY'/'RIGHT(MM-2,2,'0')'/'RIGHT(DD,2,'0')
|
|>it fails for 1700, 1800, 1900, 2100, 2200, 2300 and others.
|
|You're right, and I believe it's intentional because it doesn't matter:
|
| Gilbert Saint-flour
| http://members.home.net/gsf/
___________________________________________________
It does matter. People take these (almost general) date conversion
programs and use them in other programs.
If a program has a bug in it, at least put a comment in the code saying
something to that effect; that it's limited to the years 1901 --> 2099.
Of course, it would be better yet if the bug was fixed. I don't want to
believe that the bug was intentional, since I try to write boilerplate
subroutines, especially routines posted, or stored in a shared
database such as the CBT.
I.E.: check for the leap year, 100 and 400 year rule, check for a valid
YYYY and DDD as well, and/or missing or invalid argument(s).
Gerard S.
Gilbert Saint-flour
>>... and we'll all be dead in 2100.
>That's awfully pessimistic, isn't it?
No, it's realistic. Everybody who reads TSOREXX-L today will be dead in
2100.
Gilbert Saint-flour
Gerard S.
|In <_b6F4.725$983....@newsfeed.slurp.net>, on 31 Mar 2000 at 12:41,
|"Gerard S." <ger...@prairietech.net> said:
|
|>|>it fails for 1700, 1800, 1900, 2100, 2200, 2300 and others.
|>|
|>|You're right, and I believe it's intentional because it doesn't matter:
|
|>Of course, it would be better yet if the bug was fixed. I don't want to
|>believe that the bug was intentional, since I try to write boilerplate
|>subroutines, especially routines posted, or stored in a shared database
|>such as the CBT.
|
|(by converting an existing piece of code that was written in another
|language), I purposely left the 100-year rule out. The routine was
|intended to be used to convert system dates and it'll work until 2099
|which is pretty good, I believe.
|
|I posted this routine here in response to someone who had a problem with
|dates found in F1-DSCBs, which didn't exist prior to 1965 (or so). The
|fact that the date conversion won't work in 2100 doesn't worry me much;
|chances that it'll be still in use in 100 years are pretty slim.
|
| Gilbert Saint-flour
I understand that you wrote it for dates in F1-DSCBs which didn't exist prior to
1965.
It's still a good idea to document the bug (or feature, as you call it) stating
the
limitation of the code. A lot of people wrote code like that 30 years ago, and
the
400 year rule bit them in the rear end. At least mention that the code is
intended
only for system dates. That might give somebody a clue.
Gerard S.
|
Andy Styles
Unless it's a threat....? ;-)
Back to the topic: What about someone who was born in 1900 - converting
their birthdate won't necessarily work..
Andy Styles
andy....@natwest.com
Gilbert Saint-flour
---------------------------------------------------------------------------
The contents of this e-mail may be privileged and are confidential. It may not be disclosed to or used by anyone other than the addressee(s), nor copied in any way. If received in error, please advise the sender, then delete it from your system.
National Westminster Bank Plc is regulated by the Personal Investment Authority and IMRO for investment business. A member of the NatWest and Gartmore Marketing Group advising on the life assurance, pensions and unit trust products only of that Marketing Group.
Registered Office: 41 Lothbury London EC2P 2BP
Registered Number: 929027 England
---------------------------------------------------------------------------
Gilbert Saint-flour
>I'd be 132! It's not out of the bounds of possibility..
>Unless it's a threat....? ;-)
Not it's not a threat. What I meant is that we'll all be dead or retired
in 2100 - boy, you guys are TOUGH ! :-)
>Back to the topic: What about someone who was born in 1900 - converting
>their birthdate won't necessarily work..
That's right; the routine won't work in 1900 because it's been designed
specifically to convert system dates (IPL, DSCB, etc), which is what the
initial poster was trying to do (LISTDSI). Someone who wants to use the
routine to convert dates outside the 1901-2099 epoch will have to add some
code to deal with the 100/400 rules.
gsf
Wardable, Grant G
I dont know about you folk, but I'm planning to see if I can proove this
statement wrong!
-----Original Message-----
From: Frank Clarke [mailto:ni...@MINDSPRING.COM]
Sent: Friday, March 31, 2000 8:03 PM
To: TSO-...@VM.MARIST.EDU
Subject: Re: Julian date to Gregorian REXX routine
On Fri, 31 Mar 2000 16:26:30 GMT, Gilbert Saint-flour <g...@ibm.net>
wrote:
>... and we'll all be dead in 2100.
That's awfully pessimistic, isn't it?
Frank Clarke
LESLIE M GUTTORMSON
Hey, it's tough all over! I get called an "anal retentive" for
coding for the 100/400 rule and then commenting it out to save
cycles and ease the maintenance. And ... I most certainly will be
dead in 2100, I'm already a hair over 353 in dog years.
Gray, Alastair
assume), we have the following assumptions :
1. IBM Mainframes are still running under OS/430 V12R96 ? (doubtful)
2. The REXX code is still in use (more possible)
3. You still 'give-a-damn' about the code (very unlikely)
plus of course :
4. We're still using the same calendar (not a certainty).
Alastair Gray
Systems Type
> From: Wardable, Grant G [SMTP:GWar...@MAIL.SBIC.CO.ZA]
>
> Its sort of what lead us into the whole Y2K thing initially too.
> I dont know about you folk, but I'm planning to see if I can proove this
> statement wrong!
>
> From: Frank Clarke [mailto:ni...@MINDSPRING.COM]
> On Fri, 31 Mar 2000 16:26:30 GMT, Gilbert Saint-flour <g...@ibm.net>
> wrote:
> >... and we'll all be dead in 2100.
>
> That's awfully pessimistic, isn't it?
<snip>
Don
> > From: Frank Clarke [mailto:ni...@MINDSPRING.COM]
> > On Fri, 31 Mar 2000 16:26:30 GMT, Gilbert Saint-flour <g...@ibm.net>
> > wrote:
> > >... and we'll all be dead in 2100.
> >
> > That's awfully pessimistic, isn't it?
> <snip>
>
I'ld've gone with OPTIMISTIC...:)
Conlin, Ron
and make a killing converting this code to be Year2100 compliant. :-)
Best Regards.
Ronald L. Conlin
-----Original Message-----
From: Gray, Alastair [mailto:Gray.A...@PMINTL.CH]
Sent: Monday, April 03, 2000 9:58 AM
To: TSO-...@VM.MARIST.EDU
Subject: Re: Julian date to Gregorian REXX routine
OK, so given you've survived that long (Saving for the liquid nitrogen I
assume), we have the following assumptions :
1. IBM Mainframes are still running under OS/430 V12R96 ? (doubtful)
2. The REXX code is still in use (more possible)
3. You still 'give-a-damn' about the code (very unlikely)
plus of course :
4. We're still using the same calendar (not a certainty).
Alastair Gray
Systems Type
> From: Wardable, Grant G [SMTP:GWar...@MAIL.SBIC.CO.ZA]
>
> Its sort of what lead us into the whole Y2K thing initially too.
> I dont know about you folk, but I'm planning to see if I can proove this
> statement wrong!
>
Tim Lowe
code now that would have any kind of date problem at some time in the future?
And, while I am on that track, why hasn't the rexx date function been changed to
convert to/from julian dates with a 4-digit year now? (like the julian dates
in the IMS recons) Or, are they going to wait until 2100 to make that change?
Thanks,
Tim Lowe
Gerard S.
Well, I guess if we are into calling our own kettle black, I have to
admit, anal, I am. I even added comments about the 4,000 year rule
noting that it's not an accepted rule (yet), but (probably?) will be. I'm
talking about my handy-dandy, slicer-dicer of a date&time converter
(more like massager) that accepts a date (and time) in almost any
format and converts (or formats) it to any other, handling day of week,
Gregorian/Julian (J-date and J-day), Roman numerials, ordinal numbers,
(March 23rd for example), spelled-out numbers (in English only),
commatized numbers (is that word?), whole month calender or
calenders with any date (or today's date) highlighted in color, and
also supports months/days-of-the-week in 73 languages, and some
stuff like phases of the moon, Zodiac signs (old and new versions),
computes differences between two dates, can write the result to a file,
stack (queue), terminal, and/or the (REXX) RESULT, can add/subtract
years/months/days/hours/minutes/seconds to any date, and can
display any part of the formatted result in various colors (for
highlighting). I've written the code in PC/REXX and it works under
CMS and TSO (except for colors) as well.
I'm just now testing the REXX code to ensure it works under Regina.
I plan to make it available to anyone who asks when I get REGINA
to work correctly with OPTIONS 'UPPER' and USERID().
Of course, it's completely documentated (in what I think is a very
readable help file and sample use). Yada-yada-yada
You don't have to worry about the 4,000 year rule unless you are
writing code that handles any possible range of years --- .... hmmm,
well, DUH ! Anyway, pulling my foot out of my mouth .... pat-tooie !
Gerard S.