After I dropped the y2038 code into Time::Local::Extended, a few other authors were asking me to do the same for their modules. Rather than have them all ship copies of the C code and redo the XS work, I've just uploaded Time::y2038, a thin wrapper around the y2038 project.
This means you can use Time::y2038 and get 2038 safe versions of localtime(), gmtime(), timelocal() and timegm(). Also included is Time::y2038::Everywhere which replaces the localtime() and gmtime() functions for everyone. Use it once and your 2038 problems are solved in all the modules you use.
Note that the versions of timelocal() and timegm() are not compatible with Time::Local. Time::Local does some "helpful" things to the year (9, 109 and 2009 are all interpreted as 2009) making it impossible to specify certain years (like year 9). I'll leave it to Time::Local to wrap that bit of stupid around them.
Cue the "I don't care if you're fixing bugs so that code actually works, making global changes to Perl is bad and wrong!" complaints in 3... 2... 1....
Re:LOOK OUT!
schwern on 2008-10-20T19:50:36
This is why I put it in its own module, so nobody can complain they can't use X without also getting the global effect. It also tries to emulate the core functions exactly, I resisted mightily the urge to fix the interfaces.
Hopefully if someone does have a problem it will be concrete rather than vague architectural wibbling.
Re:LOOK OUT!
chromatic on 2008-10-20T21:03:45
This is why I put it in its own module, so nobody can complain they can't use X without also getting the global effect.
Wait until the first CPAN distribution marks it as a dependency.
Hopefully if someone does have a problem it will be concrete rather than vague architectural wibbling.
Been hit on the head recently? "Dear chromatic, I used your test module and not only did it find bugs, but it told me exactly where they were and how to fix them. Please die in a fire."
