Peter Farley wrote:
|| Please explain to me where future TOD/ETOD values
|| are needed in application code. Especially business
|| applications. I'm fairly sure that it's a rare application
|| that stores future date/time values in TOD format.
| Just the examples of which I am aware:
| 30-year mortgages, 30-year Treasury Bills, 50-year
| municipal sewer bonds...
| I'm not saying that dates for tracking/calculating
| information about such instruments are necessarily
| stored in (E)TOD format, but it is not unreasonable to
| want to do so (e.g., for interest calculations which
| often require number-of-days-between to compute
| interest due). In other words, these are *possible* uses
| for real-world business applications.
As we all now know much too well, business applications traditionally stored
dates in the format 'yymmdd' (or one of its even less attractive variants like
'mmddyy'), and the typical Y2k-project remedies for its ambiguity were to store
it in the format 'yyyymmdd' (or one of its even less attractive variants).
The poster whom Peter Farley quotes is clearly right about current business IT
practices, but Mr. Farley is right about what should be (as opposed to what
is)done.
Business systems are almost never designed; functional requirements are
specified, but alternative processing strategies are not examined; they grow by
accretion; and incoherence is the result. They also suffer from a fatal
confusion between the data formats that are appropriate for display or printing
and the different formats that are appropriate for computation.
In particular, as I noted on another occasion, calendrical arihmetic is
rendered trivial when dates are stored as the signed number of elapsed days
from some epoch origin, of which the two reasonable ones are:
either 1) noon 6 September -3760 (Gregorian), which is the epoch origin of the
astronomical Julian calendar,
or 2) midnight 31 December 0000, which is the epoch origin of the Gregorian
calendar,
of which 2) has the great merit that most dates of current interest (outside
geology and astronomy) are expressible as smallish positive integers. The use
of either epoch origin permits essentially all dates to be expressed as signed
binary fullword or doubleword integers, and either trivializes date arithmetic.
This is important because business systems abound in botched calendrical
computations: Before stopping my examination of therm I once counted 200
distinct loci of the implicit assumption that 1900 was a leap year in the
programs then being maintained by a single, admittedly large, insurance
company.
The other merit of these day-number data representations is that they are
easily converted back into conventional calendar dates for display/printing,
not just BC and AD (BCE and CE) dates but, for example, Jewish and
Muslim-Calendar dates or in language-dependent variats like those reflected in
'I January 2009', '1 janvier 2009', '1 gennaio', '1 Januar 2009', . . .
It is thus possible, indeed easy to store dates in a computationally convenient
form and to display/print them in any of several formats that are perspicuous
for some target group of people; but it has been and remains very difficult to
induce business systems analysts and programmers to distinguish external,
people-friendly formats and internal, computationally convenient ones.
Moreover, their failure to do so reflects a cultural and educational gulf that
will not be easy to bridge. (A scientific or engineering education hopefully
imparts some knowledge of archeology, bridge building, physics, or the like;
but more relevant here is that it changes the way one looks at th world.)
It is also worth noting that that, while Julian or Gregorian day numbers
preserve enough detail for most applications, they do not always do so, even
for business applications. SWIFT-transaction processing, real-time
demand/current deposit accounting (DDA/CDA), real-time medical-record
maintenance and the like all make use of and require the use of full
date-and-time values; and for them ETOD values are convenient where they ar not
too municipal.
John Gilmore Ashland, MA 01721-1817 USA
_________________________________________________________________
Quick access to your favorite MSN content and Windows Live with Internet
Explorer 8.
http://ie8.msn.com/microsoft/internet-explorer-8/en-us/ie8.aspx?ocid=B037MSN55C0701A
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
