Re^2: POSIX::mktime vs. Time::Local - Revisited. (perspective)

So the one that works better and on more platforms takes about 1/4600th of a second longer to run on your platform. That makes the choice pretty clear to me for most cases.

Perhaps if I were parsing huge log files where I had to convert a formatted date into an epoch date for each line, the run-time difference of about 1 second per 4600 lines would be enough to get me to use the faster but worse version.

- tye (enjoying one small piece of fairy cake)

Comment on Re^2: POSIX::mktime vs. Time::Local - Revisited. (perspective)

Replies are listed 'Best First'.
Re: Re^2: POSIX::mktime vs. Time::Local - Revisited. (perspective) by MarkM (Curate) on Jan 21, 2003 at 06:14 UTC
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... :-)	[reply] [d/l] [select]
Re^4: POSIX::mktime vs. Time::Local - Revisited. by Aristotle (Chancellor) on Jan 22, 2003 at 13:46 UTC
While I'm not certain about this, I seem to recall reading that loading POSIX is pretty cheap if you limit yourself to the imports you need. Or is that hogwash? At any rate, I'd just about always prefer Time::Local for the mentioned reasons. More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity. -- William A. Wulf, A Case Against the GOTO Makeshifts last the longest.	[reply]