Re: Standards question on edited fields

From: LX-i (lxi0007_at_netscape.net)
Date: 01/19/04 

Date: Sun, 18 Jan 2004 18:49:52 -0600

Judson McClendon wrote:

> "LX-i" <lxi0007@netscape.net> wrote:
>
>>Judson McClendon wrote:
>>
>>>"LX-i" <lxi0007@netscape.net> wrote:
>>>
>>>
>>>>We have a field that is 9 characters - a 2-digit day, a 3-character
>>>>month, and a 4-digit year. It's defined as follows...
>>>>
>>>>01 My-Date.
>>>> 03 My-Day Pic 9(02).
>>>> 03 My-Month Pic X(03).
>>>> 03 My-Year Pic 9(04).
>>>
>>>
>>>Why would you store a date in such a way?
>>
>>Who said I was storing it?
>
> I believe you, and having spent four years programming at command
> level for the Air Force myself, I understand the requirement for such
> display and print formats. I'm just curious what your specific reason
> is for having a date that is (currently) stored inside the computer in
> that form? I didn't say 'permanent storage'. :-)

We have a date/time proc that handles all our date and time processes.
There's a paragraph that's executed in the init logic of all of our
programs called P315-Get-All-Dates-Times. This fills working storage
variables with the current date and time. We support 4 different
formats (Julian, standard, military, and relational) and 3 different
references (local base, host base, and Zulu). So, in every run, you
know that

W315-Current-Date-ZJ7 (CCYYDDD)
W315-Current-Date-ZS8 (CCYYMMDD)
W315-Current-Date-ZM9 (DDMMMCCYY)
W315-Current-Date-ZDT (CCYY-MM-DD)

all have the Zulu-referenced date in the various formats. This allows
any program to display and compare the current date in any format they
may have already, without doing a lot of conversion first. (Expansion
routines are provided for 2-digit years, which we still have on several
of our screens, but not in the database.) Of course, these aren't the
only 4, but the others follow this basic design.

> Perhaps it's changed a lot in the three decades since I was in the USAF,
> but I saw lots of crummy design. Lots of good design too, of course. :-)

This design is brilliant (and I can say that without being cocky because
I'm not the one that came up with it, although I'm now the custodian of
it). There are many date/time routines (addition, subtraction, range
checking, offsets, etc.) in this proc, and a recent performance
evaluation, which I thought would flag a lot of problems in it, actually
showed that it's some of the most efficient code we've got, in terms of
processor cycles and time. 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          LXi0007@Netscape.net          ~
~ _____ /  \      |  ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~         I do not read e-mail at the above address           ~
~    Please see website if you wish to contact me privately   ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~