> its not my data i am stuck moving this data from a sad access database > designed by a moron. anyway it means i will have to do alot of work on > the script to make it fix that, or just install an old version of pgsql > on a box here and pg_dump the table which seems easier.
I've ported a lot of data from legacy systems with 6 digit dates in them (mmddyy), not all of which were addressed for Y2K. For each system I usually wind up writing one or more to_date functions, so that I have a consistent set of rules being applied. Depending upon the specific application, those functions will have different switchover points between 1900 and 2000 as the base century. Sometimes I have to supply an additional parameter to help decide when to switch over. For example, if the data includes other age-based qualifications, such as whether someone is a child or a senior citizen, that offers another clue as to whether '02' in a birthdate is 2002 or 1902. Depending on how clean the data is in the first place, that might not fix all inconsistencies, though. Another reason for having my own date conversion function is consistency in dealing with bad dates, like 05/32/2004 or 11/31/2004. In general, I think that date conversion decisions are an application design issue, not a database system issue, and the fewer such decisions that are made by the database, the better. -- Mike Nolan ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
