Home
This project is in need of an experienced C programmer to apply C best practices and review the code
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 first goal was to replicate localtime() and gmtime() in order to allow Perl to work around a system's 2038 limit. This has been accomplished and in Perl since 5.12.0.
The next goal is to complete all the POSIX functions and improve our compliance with the spec.
The y2038 project is funded in part by a grant from [The Perl Foundation](http://www.perlfoundation.org/ The Perl Foundation).
The following functions are implemented and well tested.
- localtime64_r()
- localtime64()
- gmtime64_r()
- gmtime64()
- timegm64()
- mktime64()
- asctime64_r()
- asctime64()
- ctime64_r()
- ctime64()
This complies with the POSIX standard for time.h and will work with any decent ANSI C89 compiler.
Please send a message to y2038-users, or do a code review, or post and issue, or try to fix an existing issue or try out the code on your machine and let us know how it works out.