Re: Date fields and moving from yyyymmdd to mmddyy

Booth,

I know you're irritated, but step outside your irritation with me for a
moment.

Consider that not all applications are dealing with 2 centuries, 1900s
and 2000s. As an example, consider a museum that has objects that date
far back in the centuries.

Now, let's look at that in the context of your desires to work outside
the 40 - 39 window with 2 digit years. The system has to have a way to
determine what century you're referring to when you use 2 digit years,
otherwise there is no integrity. So, while YOUR users might know that if
the see a birth year expressed as 22 that it's 1922 and not 2022 because
2022 hasn't happened yet and you can't be born before your birth year
happened, that's not the only consideration. In the year 2023, a birth
year of 22 could mean either 2022 or 1922 because it's certainly
possible to be 101 years old (we should all be so lucky). The point is
that there are applications and circumstances that require removal of
ambiguity and the only way to do that with 2 digit years is to define a
100-year window that implicitly defines the century.


Gary Guthrie



boothm@earth.Goddard.edu wrote:
> 
> I think what irritates me most though is that we can not use the new
> solution to move an 8-digit date to a 6-digit date outside the 40-39
> window.  Users understand birthdays.  If they see a birthday of 3/31/22 on
> their screen they know it isn't 2022.
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---