Clone this wiki locally
This project is in need of an experienced C programmer to apply C best practices and review the code
This project is in need of more cross platform testing
The goal of this project is to provide a drop-in replacement for POSIX time.h which will work on machines which have a 32-bit time_t, yet not suffer from the 2038 bug. This will allow C programmers to be 2038-safe without having to rewrite their software to a new interface. It does this while still using the system time zone database.
Many Unix time and date functions cannot calculate a date beyond Tuesday, January 19, 2038. This is known as the Year 2038 Problem and it effects most Unix and Macintosh computers currently in use.
Unlike the Y2K bug, it is by design and we know how to fix it.
time_t, the data type which stores time on Unix, is normally only large enough to hold time up to 2038. Making it larger would solve the problem. Many 64 bit operating systems have done that, but that requires recompiling much of your software, so many have not. For example, most Macs run on a 64 bit processor but still use the smaller 32 bit time_t.
Our first targets are Perl, Ruby and Python.
The next goal is to complete all the POSIX functions and improve our compliance with the spec.
The following functions are implemented and well tested.
This complies with the POSIX standard for time.h and will work with any decent ANSI C89 compiler.