According to Benchmark, POSIX::mktime is about 700% faster.
Benchmark: timing 20000 iterations of POSIX, timelocal... POSIX: 1 wallclock secs ( 0.57 usr + 0.03 sys = 0.60 CPU) @ 33 +333.33/s (n=20000) timelocal: 6 wallclock secs ( 4.95 usr + 0.00 sys = 4.95 CPU) @ 40 +40.40/s (n=20000) Rate timelocal POSIX timelocal 4040/s -- -88% POSIX 33333/s 725% --
Being written in Perl, and not C, Time::Local should work everywhere Perl does. And looking at the source, I don't see anything that may fail as long as Perl is working properly.
According to the docs of Time::Local
Please note, however, that the range of dates that can be actually be handled depends on the size of an integer (time_t) on a given platform. Currently, this is 32 bits for most systems, yielding an approximate range from Dec 1901 to Jan 2038.And as POSIX::mktime() returns undef when I try to give it a date past 2038, I assume it fails for the same reason.
In reply to Re: POSIX::mktime vs. Time::Local - Revisited.
by Paladin
in thread POSIX::mktime vs. Time::Local - Revisited.
by BigLug
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |