Re: Year 2000 (or Year 292 BILLION) fix??

On Wed, 10 Sep 1997 09:52:35 -0400, Glenn Ericson
<Glenn-Ericson@att.net> wrote:

>>So: Could we not create a "standard" database date format, being 64
>>bits (8 bytes, no larger than current Year 2000 efforts) that
>>represents the date AND time of some event. Now: an OS API that can
>>convert the current date and time to some 64-bit number, and can take
>>some 64-bit number and make a date and time stamp from it. 

>That is  wonderful on the  date width.

>How does it make it easier and faster?

>Can you take it a little further and  explain how  this method will  work:
>-  in the application and EIS (Query),  client server and other electronic
>trading partners systems [whoever manufacturers / programs them]

>-The  end user  understandability

It's easier and faster because there's only one date and time format.
Work databases (non-normalized) could utilize multiple format for
end-user querying, but production databases would only use this
format. It saves space in databases that store the date and time in
two fields, please keep reading for why. If two systems interchanged
data, it's an 8 byte number, and contains date AND time. Sending the
date minimum would be 6 digits (without the century), and sending the
time, hours, minutes, seconds, is also 6 digits. So sending a "normal
date and time is 12 digits, 14 for four-digit years. This format saves
bandwidth, at the expense of some CPU cycles to reconvert it to
human-readable date/time. Programs utilize only this format for
internal date processing. (These are the things I can think of
immediately...)

How does it all work?

Databases wil have this huge 64-bit number representing the date and
time. OS APIs will translate that number to and from the corresponding
date and time. 

In traditional programs, like RPG, would call the special OS API to
translate the date/time, and store it in a 64-bit numeric field in the
program. Then any date+time comparisons would be easy. 

Matter of fact, RPG could use something similar to the TIME opcode:
the TIME opcode returns the current date, and optionally, time,
depending on the width of the result field. The bignum API could do
the same. 

Querying tools, in my view, would have BIFs (built-in functions) that
call this API. Now: you could store the calendar date and/or time in
your databases as well, and incur the increased data storage cost, but
would make adhoc querying a breeze. Or, say in Query/400, you create
user-defined fields MYDATE and MYTIME, passing that huge number
through a BIF: MYDATE = BIGNUM2DATE(bignum) or somesuch. It would have
to be done in each query.

OK. The major problem with this scheme (and anything else that travels
outside your computer system) is "how will the other computer handle
it?" Data interchange will be the biggest hurdle against my
suggestion. 

All the "trading partners" would have to have some way of handling
this 8 byte number. Some cannot. A common format must be agreed upon,
and supported in the same way in all systems that exchange data. I
think even 32-bit systems (many Unix boxes, CISC AS/400s, 386/486
systems) could also perform program this API through register voodoo.
The API could even have "shortcuts" or pre-programmed conversions. For
instance, if I only care about calendar dates, then I know each day
increments at 86,400 seconds. The API could "assume" midnight on a
given day and count in 86,400 increments. Assuming a standard
calendar, the API would also know how to handle leap years (of which
2000 is one). In counting years, the API could assume 365 days, or
31,536,000 seconds, and add the appropriate day every 4 years. Similar
shortcuts could be used in time calcs.

Performance? I don't know. With the problems of RPG IV native date
types being discussed in this list, performance could be okay or poor.
Using the above shortcuts, performance might be quite good. However,
that becomes increasingly irrelevant as newer and faster systems are
introduced. (Not to say we need to write inefficient code, but faster
systems can alleviate the "slow code" problem.)

I'm sure I missed some points. I'm always open to suggestions and
thinking debate over this issue.

 - lg -

--
A book: ...turn a page, read, read, read, read...
Television: ...click, watch, watch, watch, watch...
The Web: ...click, wait, wait, wait, wait, read...
lgoodbar@tecinfo.com  ICQ#504581  http://www.tecinfo.com/~lgoodbar/
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MAJORDOMO@midrange.com
|    and specify 'unsubscribe MIDRANGE-L' in the body of your message.
| Questions should be directed to the list owner/operator: david@midrange.com
+---