On 2000-Mar-24 Nagi wrote:
> Thank you Ian for the lengthy reply and some great insights and
> weblinks. The problem I am trying to solve is - the user is used
> to inputting 2 digit years in the application. Our database always
> stores 4 digit years. However, before I insert the data, I need to
> convert the user provided 2 digit year to a 4 digit year. This is
> where I am not sure how to set the ground rules. I hope that helps
> you understand the context of my question.
Yes. This is a problem. You need to examine what data is going in, and set
the 100-year range accordingly. If the application involves (for example)
Date of Birth information, you need to see what age are all of the people
who are being stored. If it is always children, then set a pivot date of say
1970 or 1980, and you will not have to modify your program until 2070. If
you deal only with elderly people then you can just prefix all dates as
19xx, as you will not encounter a 60 year old person born after 1999, until
after 2059. People born in 18xx will already cause you problems, unless you
run the window from say 1890 (this allows a 110-year old person to exist in
your data) to 1989 (no-one under 11 can exist in your data this year, under
12 next year, and so on - when this figure reaches say, 50, you need to move
your pivot dates again).
This is a difficult problem, and will take a lot of time to resolve with
your client. Any Windowing solution will need constant review to ensure that
no-one tries to input data that could be wrongly interpreted by 100 years.
It would be easier in the long run, to convince your client that the use of
two-digit year date formats is extremely unwise. However, if they still
insist that a two-digit year date must be used for input, you must insist
that all dates are always immediately displayed and printed using all four
digits, so that wrong data can be easily spotted. For example, in 2006, a
user types 02/02/02 for a date of Birth of a person 104 years old, and the
dispay shows 2002 Feb 02, so alerting someone to the fact the computer
assumes that this person is only 4 years old.
The biggest problem is that you may need different Windows for different
data fields. For a mortgage database of standard 30 year terms for example,
you may require three fields: Date of Birth, Date Mortgage Started, and
Completion Date. There will be no-one aged less than 18 in your data, but
some people may be up to 70 or 80 years old. Current mortgages will have
been started sometime in the last 30 years, and more will be taken out in at
least the next 30 we will assume. Current mortgages will complete sometime
in the next 30 years. Mortgages taken out in 30 years time will complete in
60 years time. So your data could span 140 years (from oldest Date of Birth,
to final payment of a mortgage completing in 60 years time), and requires
different windows rules for different fields. Now you know why so many
people recommend using all four digits for the year, and adopting the ISO
8601 Year-Month-Day date format.
Perhaps you already know all these things, but I hope this helps. Plese see
if you can find the IBM Year 2000 Book on the WWW, this discusses Windowing
in more depth. I have a link to an old copy of this document on my Web Site.
The publication number is GC28-1251-xx (where xx is the version number from
01 to perhaps 07 or 08). You may also find it by following links from IBMs
main Web Site at <http://www.ibm.com/
There are a number of great Web Pages about the ISO 8601 standard. Follow
the various links from my Web Site to pages written by Markus Kuhn, Steve
Adams, and others. These people are the real gurus! A short text at (or
linked from) <http://how.to/FormatDates/
>. is also useful. There are many
others: try your favourite Search Engine for more:
> or whatever.
By the way. Which country are you in? I'm in England, UK, Europe. This isn't
obvious from my email address, or Web Page address either.
There is an email discussion group about ISO 8601. If you want to join, then
>. It is a low volume list, but
brings many of the core 'activists' worldwide together, to share ideas.