The y2038 project is unique amongst the 32 bit fixes for the 2038 bug in that it does all three of these:
A) Is compatible with the standard time.h C library
b) Handles time zones
3) Does not ship its own time zone database
For example, libtai is awesome, but it doesn't support time zones and doesn't look much like time.h.
The decision not to ship its own time zone database is important. They contain not only time zones but daylight savings time. They are bizarre and archaic and a job best left to somebody else. When they fail to be updated, bad things happen. Things I do not want to be responsible for. Time zone databases are part of your system and get updated, quietly, with your system. I don't want the user to have to update a second time zone database.
The C interfaces for talking to the time zone interface are very poor and not very standardized. localtime() and mktime() are about all you can rely on. But localtime() was the start of the whole problem in the first place!
y2038's implementation of localtime() relies on the fact that you can map any calendar year to another calendar year. Once you realize that, you can map a date after 2038 to a date before 2038 and take advantage of the 32 bit system functions!
Of course, it's not quite so easy. The calendar cycle is 400 years long. The range of 32 bit localtime() is 138 years. But I came up with an algorithm to account for that and map 400 years into just 28. You can read about it here.
