The UnixTimestamp() function in the framework has a PHP counterpart that is faster and accepts more diverse inputs.

include('Framework.Functions.php');

$TestNow = MySqlDateTime();

$tm_start = array_sum(explode(' ', microtime()));
$secs_total = 0;
$IterationCount = 0;

while ($secs_total < 5) {
UnixTimestamp($TestNow);
$secs_total = array_sum(explode(' ', microtime())) - $tm_start;
$IterationCount++;
}

echo "\r\nUnixTimestamp() ran x times: ".$IterationCount;

$tm_start = array_sum(explode(' ', microtime()));
$secs_total = 0;
$IterationCount = 0;

while ($secs_total < 5) {
strtotime($TestNow);
$secs_total = array_sum(explode(' ', microtime())) - $tm_start;
$IterationCount++;
}

echo "\r\nstrtotime() ran x times: ".$IterationCount;

This results in this output:

UnixTimestamp() ran x times: 151558
strtotime() ran x times: 433745


I thought this could have been the source of the Daylight Savings Time bugs: [1], [2].

My first thought is there is some ambiguity in the conversions during daylight savings time. But all my conversion tests between these two match clean.

It seems that strtotime() relies on the regional daylight savings time settings of the server, so it just might be that I need to explore those more closely... It could be that UnixTimestamp() exists to keep those settings from causing some bug... yet UnixTimestamp() makes use of mktime() which also guesses DST based on regional settings.

So there could be a performance increase by replacing all the calls to UnixTimestamp() with strtotime() as well as just making UnixTimestamp() a direct call to strtotime(), as some extensions call it directly.

...unless there is a good reason UnixTimestamp() exists.

for 1.2 version?