An additional argument for Time::Local, is that POSIX is huge.
However, to contrast this line of thinking:
The converse function to timelocal(), localtime(), does not accept a granularity smaller than second units.
Specifying seconds as a floating point number invites rounding errors when performing any calculations. IEEE 64-bit floating point numbers offer 52 bits of accuracy, not accounting for rounding errors. On most Unix operating systems, time_t is a 32 bit unsigned integer. This leaves only 20 bits to represent fractions of a second, and deal with rounding errors. For a decimal comparison, floating point is accurate to 14 decimal digits, and 32 bit integers are as large as 10 decimal digits. This leaves only four decimal digits of accuracy below second units.
It is easy to keep seconds and microseconds as separate integers. Not only are the calculations much more precise, but this model improves future portability with time_t values that will likely be 64-bit unsigned integers.
POSIX::mktime() can be implemented on other platforms, and in fact, is implemented on other platforms. Notably, the few tests that I performed using ActiveState Perl Build 633 on WIN XP seem to generate valid results.
That all said, I personally often use Time::Local::timelocal(), and only rarely use POSIX::mktime(). I suspect this is more a case of habit, than anything else... :-)
In reply to Re: Re^2: POSIX::mktime vs. Time::Local - Revisited. (perspective)
by MarkM
in thread POSIX::mktime vs. Time::Local - Revisited.
by BigLug
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |