Press release of the 1998-08-12
A solution to the 2000 year problem - solved differently!
Much has been written about the problem of the year 2000 and many programs have been offered - so many - like sand in the ocean. In the meantime, one knows the causes of the problem quite well. Because the programmers wanted to save space they used the last two digits of the year only in writing programs. However less known is the fact that the date algorithms too were implemented erroneously. The best example to mention here are the internet RFC of 1095 and 1189 in which the leap year algorithms are described wrongly. Furthermore one has to be aware that the year 2000 problem will recur later on again and this is not a known fact. The reason for the recurrence lies in the various realizations of handling dates and time. Unix for example uses a 32 bit wide counter for seconds which is 'filled up' so to speak in the year 2038. Similarly one can compare it to Amiga, only here the spill-over occurs in the year 2078. Many 2000 problem solutions simply move the real problem, the correct date calculation, by some years to obtain a little breathing room and hope to solve the 2000 year problem change for the immediate time.
Why - some wonder - isn't the problem fixed once and for all for everyone and everything. This question is primarily of importance when one considers where date calculations are applied. Not only are they applied in systems having something to do with date/time but also in public transportation like air travel, train systems, or in the medical field, in hospitals the controlling mechanism for the sick or heating installations, lifts, entrance controls etc. just to name a few. On the surface it doesn't look like a big deal to calculate dates on the surface - simple and uncomplicated. But when examined in more details, its very complicated than first anticipated. The result is shown in the complex year 2000 problem phenomena.
In order to solve this problem software engineering comes into the picture. The methods mentioned here is the reuse of components. Reusable components have the advantage that a problem isn't only already implemented by it but also was tested. Should a problem cause insufficiencies later course anyways, only the component must be looked at without the remaining software being affected. Such a platform independent component which was developed especially for the date and time calculations is the DateLib (TM) of Hofmann Software Engineering International. This component is not only able to solve the year 2000 problem forever but the software is suitable for the international market as well concerning the date/time zone problem. This appears particularly important in connection with the World Wide Web.
Prospective buyers can see not only the documentation under http://www.hofmann-int.de/ in PDF format but beyond this, also test everything via the 92 available functions. So this makes it possible to test the software before a purchase and the buyer can make up his mind on this basis whether to buy the program DateLib (TM) or not.