y2038

This project is in need of an experienced C programmer to apply C best practices.

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 first goal is to replicate localtime() and gmtime() in order to allow Perl to work around a system's 2038 limit. There is now a bleadperl branch for the 2038 fix.

The y2038 project is funded in part by a grant from The Perl Foundation.

What works?The following functions are implemented and well tested.

localtime64_r() localtime64() gmtime64_r() gmtime64() timegm64() mktime64() asctime64_r() asctime64() ctime64_r() ctime64() What platforms?This complies with the POSIX standard for time.h and will work with any decent ANSI C89 compiler.

Want to help?Please send a message to y2038-users, or do a code review, or post an issue, or try out the code on your machine and let us know how it works out.

Tags

  gmtime timeh 2038 localtime time c y2038 date

Share