Re: Two digit date window

[Portal39@xxxxxxx]

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