|
I can offer a couple possible reasons why an 8 digit date might be a good idea. None, some or all might apply to your situation. And you might not agree with them :) *disclaimer - After I re-read my message, I realized that I mixed in some arguments about why you should use L-date fields along with the arguments for 8 digit dates. I made an assumption in doing that which may not be true - what do you mean by *M36? The RPG36 on an AS400 can use a dds defined L-date field without any problems. I don't know if *M36 can or not. That leads to the issue of whether or not to define your files, I suppose. Another day for that one. Consistency - while some fields might not ever contain 19xx dates, might some others? It would be a good thing to be able to say date fields are always in X format instead of some in 6 some in 8. Conversion/Acquisition/Consolidation - If you buy another company (or another company buys you) you might have to import data into your new system that you thought would never have 19xx data. That scenario may be a stretch but there are lots of reasons that old data gets imported into new systems. Code lifetime - you say that it is a *M36 installation and likely to remain so. Obviously, I can't debate your situation, but I bet there are a lot of shops like ours where parts of the database are older than some of our programmers. If that code lasts 20 years, will it still be a *M36 installation? Maybe, but then again, maybe not. The programmers who follow you will be happier if you set the database up to use L-date fields right from the beginning. Query & SQL - Both of these tools can manipulate L-date fields in ways that are impossible (or very difficult) with dates in numeric or character format. Tools - If you use a data analysis tool on your data (or if you export or download data to one) it might be easier if it has a 4 digit year or is a L-field. Larry Paque larry@paque.net ----- Original Message ----- From: <boothm@earth.Goddard.edu> To: <rpg400-l@midrange.com> Sent: Sunday, February 06, 2000 9:53 AM Subject: Y3K or not to Y3K > An interesting question was just asked here. Why, on a brand new > application with no dates prior to Jan. 1, 2000 are we using an 8-digit > date? L-Date fields are not relevant - this is an *M36 installation and > likely to remain so. > _______________________ > Booth Martin > boothm@earth.goddard.edu > http://www.spy.net/~booth > _______________________ > > +--- > | 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 > +--- +--- | 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 +---
As an Amazon Associate we earn from qualifying purchases.
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.