Year 2000 Problem


About time - whats wrong here!

As can be read everywhere there is going to be a problem in calculating dates correctly when we reach the year 2000.

The main problem is that programmers use most of the time the last 2 digits of a year and not the century. This happens because it's shorter to write and also it is a rarity that we humans will be older than 100 years.

It seems that most programs can't handle 00 correctly. It's because they often do not allow the use of 00 as an input for the year - or this might mean 1900. However this is really only a small problem, because the question is actually how the algorithms working behind the input fields, seen by the user, really look.

It could be that these algorithms will only work for a range from 1900 to 1999. From known calendar software one can see that the algorithms behind will function only for a range from 1900 to 2100. This is a very special range since it is extremely easy to calculate on. To calculate wider ranges however, you have to be familiar with astronomical phenomena of earth, sun and moon. The problems appearing in the year 2000 are not only the fact that the input fields accept only 2 digits for a year (and it may not necessarily be 00). Calculating dates is not everyone's cup of tea. In the year 1582 Pope Gregor XIII undertook the task of the so-called 'Gregorian Calendar Reform' in order to fix the relation between the months and the seasons. To make this correction he deleted 10 days from October 5, 1582 to October 14, 1582 from the calendar. The problem with that was that this correction was done by different states, governments and municipalities at different times.

Now lets get back to the problem of the year 2000. The weekday of 1.1.1900 was a Monday and the weekday of the 1.1.2000 will be a Saturday. So, one can see that the programs get confused. If the programs thinks that year 00 means 1900 they will calculate all weekdays of the year incorrectly. IT WILL BE CHAOS!

Another disturbing aspect of the year 2000 is that the Gregorian Reform defines algorithms to calculate leap years in a way which should protect us from the fact that the months will be displaced once more against the season. To calculate whether a year is a leap year there are these three rules:

As one can see, one more difference between years 1900 and 2000 is the fact that year 2000 will be a leap year while year 1900 was not a leap year. Btw. the leap year algorithm has been described wrongly very often - for example within the internet RFC's 1095 and 1189 you can read the following wrong algorithm description:

In the Gregorian calendar, all years have 365 days except those divisible by 4 and not by 400, which have 366.

The 4 year rule is correct, the 100 year rule is missing and the 400 year rule is incorrect given!

All these problems are really basic problems. By not calculating correctly, your software will calculate other things incorrectly too, like:

Last but not least the year 2000 problem will return in 2038, 2078, 2100, ... for different systems like Unix etc. depending on the implementation of the calendrical algorithms. Maybe you will think now that 2038 is far away - but that's what people had thought writing software in 1960 about 2000?


Now lets attempt to describe solutions to make your software safe and useable for the year 2000 and beyond.

Be careful and prudent, please, when trying to find solutions to the year 2000 problem. There are numerous people trying to make a quick fix - what they really want is a quick buck - sadly to say. For example do NOT trust people who talk about the 'Milennium bug', since they don't know what this is all about. The next millennium starts at 2001-01-01 and NOT 2000-01-01 for your information.

The problems to be addressed are twofold:

For the first problem there is a very easy and powerful solution. You can license the DateLib (TM). This library enables you to calculate leap years ranging from the year 8 to the year 8000. You will see quickly that this library will make your own software safe for the next centuries to come!

If you are thinking about developing your own date calculation library I will tell you that this is most labor intensive and may cost you a pretty penny in development costs (estimates run up to US$150,000).

Let me address the second problem, the problem of handling years that are only defined by two digits.
You can divide it into two parts:

In the first case your problem of converting a two digit year into a four digit year is easy. You have only to ask your environment (operating system) for the actual year. Now you can calculate the century for a two digit year by using the 'sliding window technic' described below.

The second case can only be handled with the help of the user or may be with a predefined year.
The idea is as follows:

Think about the time as a never ending line. Over this line you will move a window, which displays only 100 years to you. In the middle of the window will be the actual year. In front of the actual year are 49 old years, and in following the actual year there are 50 years that are lying in the future. By increasing the actual year, the window will move into the future direction.

Now you only need the actual year or a year that is similar to it (like the year your software was released). If your software has only 2 digit years you can now compare them to the window whether they are years of the past, present or future. By often using future years you can move the window to this future to be up to date with your calculations.

Take care in fixing old software or developing new software correctly since the problem for the year 2000 at hand might come back to hunt you in the year 2100 (and then it might be more difficult to correct).

The Year 2000 Problem
and how the DateLib (TM) can be of use

Should you be troubled with the Year 2000 Problem (and who isn't), then things might become easier to manage and simpler to solve if you will use the DateLib (TM). This library will give you low level functions for all kinds of date and time calculations. For example, the simplest function is the one to find out if a year is a leap year. Other functions will return the weekday of a date, check the validity of a date, compare dates etc. Higher functions will calculate the number of days between two dates or the day and month of Easter Sunday in a year.

Especially for the Year 2000 Problem there is a function that can supplement the century for a two digit year by applying a sliding window technique. This will allow you to leave your two-digit-year user interface elements untouched!

Last but not least the DateLib (TM) gives you very powerful formatters and parsers for creating and parsing date and time strings. Month and weekday names can be read and written in 21 languages. The date-string-parser is able to autoanalyse over 40 date-string formats, but it is possible to parse an unlimited number of string formats via the template mechanism.

The DateLib (TM) is written in strict ANSI C/C++ that should work on any system providing an ANSI C or C++ compiler. This means to you, that every software written in C, C++ or a language supporting an interface to C or C++ can use the library! Additionally every language which allows you to access shared libraries (also called dynamic link libraries) will be able to use the dynamic power of the DateLib (TM) in order to help you fix the Year 2000 problem as well as implement or improve your date/time handling only, should you so desire.

To make use of all the powerful features which will help you fix your Year 2000 Problem, there is one thing left for you to do: You still have to identify your old program code responsible for your Year 2000 Problem. Only this should be small compared to the feature of correct date calculations ranging for the years 8 to 8000 that the DateLib (TM) will bring to you.