Bernie, your observation is spot-on and lemme' add to your comments. Of course, all this is predicated upon the req't that input is governed by "SET DATE SEQUENCE MMDDYY". The actual pivot value, in this case, 80, is dictated by context. We had a situation during that Y2K work I previously mentioned where this occurred. The (HR) system-wide pivot year (SET DATE YEAR) was 40.
This was fine until Dependent Spouse Benefits functions were invoked during testing. At that point, a (dwindling due to age and death, but still legally significant) number of surviving spouses were denied benefits, such as pension checks, healthcare coverage, etc. The reason was that marriage dates occuring prior to 1940 were pivoted into the 21st century, meaning that, although they were in reality true events, the system determined that the events were false, as the marriage date was in the future. The system worked the way it was supposed to, it was just not working the right way when compared to reality. Lemme' add that when this happened, based upon previous work and sufficient trust between myself and the development team leader (the environment was IBM mainframe, OS/390, COBOL, and CICS) they came right to my office and asked me to tell them what the system pivot year should be for this context (my words, but you get the point). I said gimme' a few minutes - I hadn't worked w/the data in a few weeks, so I had to re-familiarize myself a bit. So, while many DBMS's might have been suitable, I used RBase, LISTed the tables, LISTed some COL's, CREATEd a VIEW or two, executed a SELECT, OUTPUTting to a text file the result-set. Then I printed it and walked it down to the "war room". They were not only happy, but impressed, as total cycle-time was < 15 min's. Well, I could go on about how I used RBase during that effort, but, in general, I'm not one to gratuitously praise a product, but rather intelligently/rationally critique it. Let's just say that the way I used it and my brains saved that organization some money and made me look pretty good. Later, Steve in Memphis ----- Original Message ----- From: "Bernard Lis" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, August 20, 2002 3:45 PM Subject: Re: Date Dilemma > Hey Bill, > Setting the date year to 80 is kinda dangerous, if you were born on 1-1-79 > your birth date would be 1-1-2079 - which means you haven't been born yet. > > I've been using 30 for the year and tell all my customers to call me every > 10 years to update it <g>. But I do show them how to do it. I suppose I > should start putting in a utility on the menu for this purpose. > > Bernie Lis > Megabytes, Inc. > > > Pick a different year if you want, but don't leave it 00. The Date Year is > for 2-digit data entry: If someone types in a two-digit year below this > number, one century is added to the DATE CENTURY setting. A > number at or above that number gets the DATE CENTURY at the > beginning. So, with DATE YEAR 80, 1/1/81 is stored as 1/1/1981, but > 1/1/79 is stored as 1/1/2079. > > ================================================ > TO SEE MESSAGE POSTING GUIDELINES: > Send a plain text email to [EMAIL PROTECTED] > In the message body, put just two words: INTRO rbase-l > ================================================ > TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] > In the message body, put just two words: UNSUBSCRIBE rbase-l > ================================================ > TO SEARCH ARCHIVES: > http://www.mail-archive.com/rbase-l%40sonetmail.com/ ================================================ TO SEE MESSAGE POSTING GUIDELINES: Send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: INTRO rbase-l ================================================ TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: UNSUBSCRIBE rbase-l ================================================ TO SEARCH ARCHIVES: http://www.mail-archive.com/rbase-l%40sonetmail.com/
