× 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: Jon.Paris@xxxxxx
  • Date: Mon, 18 Jun 2001 10:19:26 -0400


 >> 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
Jon.Paris@e400.com

www.e400.com - A new wave of iSeries and AS/400 Education


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

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.