On Jan 20, 10:41 pm, alexey.sal...@gmail.com (Alexey Salmin) wrote: > I'm just curious: why localtime is a built-in function but timelocal > is in a core module?
I really can't say for sure. Unfortunately the history of Time::Local's introduction into Perl 5 is lost. http://perl5.git.perl.org/perl.git/commit/a0d0e21ea6ea90a22318550944fe6cb09ae10cda And p5p doesn't go back that far. > 3) Function, which is a wrapper to a system call or Standard C Library > - built-in, otherwise - library. > At first blush it seems that this approach is not used here either: > there are localtime(3) and mktime(3) functions both in the Standart C > Library. But reading the docs > (http://perldoc.perl.org/Time/Local.html#IMPLEMENTATION) leaded me to > a conclusion that timelocal doesn't use mktime(3). This is correct. > At this point it > all started to make sense: localtime - wrapper to a localtime(3) from > C library - built-in, timelocal - complicated function - library. > But that puts another question: WHY timelocal doesn't use mktime? > There are also different possible reasons I can imagine: > 1) mktime is not supported everywhere? Not likely actually. It is in > Standart C Library since C89. Taking in account that early perl > versions appeared somewhere around 1987 I don't think that it is the > real reason. There is a configure flag for HAS_MKTIME. I wouldn't be surprised if at the time (1994) there were systems which did not have mktime(). > 2) timelocal guarantee 100% compatibliry with localtime. May be > mktime(3) is not completely compatible to localtime(3)? Haven't heard > about such issues. Anybody can comment on that? I can't speak about back in 1994, but at least inside a 32 bit time_t range localtime() and mktime() are symmetrical. 64 bit times fall apart, mktime() often stops working at year 0. My speculation is the problem is not timelocal/mktime but timegm. The GMT version of mktime() is timegm() but it is a GNU extension not always available. Otherwise there is no standard way to reverse gmtime(). The work around involves changing the time zone temporarily to GMT, calling mktime(), then putting the time zone back. This might run afoul of Portability problems (I say that with a capital P to emphasize just how portable Perl is). I guess they figured if they had to write timegm() in Perl they might as well write timelocal() as well. If you look at the original Time::Local you'll see that timelocal() is implemented (questionably) in terms of timegm(). The other thought is it was written by a Perl programmer and XS was even more terrifying in 1994 than it is now. I think nobody's bothered to write an XS version wrapper around mktime() since. Might be interesting to do. Time::y2038 provides an XS wrapper around the C functions (actually its own 2038-clean versions) and benchmarking shows it to be about twice as fast as Time::Local. I honestly expected more.
