× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Two digit date window
  • From: Portal39@xxxxxxx
  • Date: Mon, 18 Jun 2001 12:32:58 EDT

Jon going to hold you from your real work for a moment.

Ever so many people did not use date data types.
They developed their own routines to pivot dates and then store them on DASD
as they did before the birth of date data types.  Many package vendors too !!!
Thus, internal pivot days  should  be important and  sensitive to change as
well,  


Jon.Paris writes:


>> 1939 or 1927  or 28 and below go Boom too under  the 1940- 2039 theory

>> All windows are only as stable  as  their internal pivot year relates
to the dates received for processing. YES/NO?


Yes - but ..........  Maybe I'm not saying things very clearly.  Let me try
it this way and then I'll get on with real work <g>



"Real" dates on the database don't really have a pivot year - they are
stored as a day count - not as year digits subject to pivot interpretation.
The value stored on DASD will be the same for Jan 1st 1940 regardless of
whether DATFMT is *MDY or *ISO.



Let's say I have designed a database.  It includes a "real" type L date
field, because I was told it would guarantee that only valid dates would
ever be stored.  I chose DATFMT(*MDY) as the format for that date because
that is what my users like and because the dates will _never_ go outside
the range 1950 - 2020.



This works well for a while until one day IBM decides to change the date
window.  Instead of 1940 - 2039 the window is moved ahead 20 years to (say)
1960 - 2059.   The first time that my application reads a record with a
date in the 1940 - 1959 range it will blow up.  Not on every record - just
anywhere the stored binary day count equates to a date outside the new
range.  Not only that it will do so in a way that gives me no way of
effectively handling the error, since it will occur while the buffer is
being unpacked.



In order to resolve this I would have to do a CHGPF with new DDS that
changes the *MDY format to (say) *USA (I am assuming that this works -
can't think why it shouldn't - otherwise I have to copy the file).  But
then I have to modify all my programs to handle the 4 digit year.  That is
not acceptable to me.  I used "real" dates for reasons of integrity - a
change in the window broke that rule.  I now have dates stored that are
outside the window, and I have no choice but to change my programs to
accept 4 digit years.







Jon Paris



As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.