In a new post to his blog Terry Chay looks at the real cost of a (call to) date() - the PHP function that can parse either the current or an inputted timestamp out into the date format you specify.

One of the fringe benefits of open sources an existing code base is that you have an opportunity to setting error_reporting on E_ALL | E_STRICT or perhaps rather just to 2147483647. When you do that you find small problems with your code base you missed the first time you sloppily wrote it. In my case, I noticed that date() was throwing strict errors.

Due to his resulting request to test the error (after submitting a ticket to fix the server's php.ini settings), he went about trying to test and see what the real impact of working with the date function was by developing his own simple benchmarking script. It runs through five different tests some with a default timezone set and some not. His results found that doing it in the script versus on the server's config didn't make much of a difference so he corrected the issue with a quick ini_set (or a date_default_timezone_set).

On his blog today, Joakim Nygard has posted about the use (or disuse) of time zones in PHP:

The problem with not handling timezones correctly is not apparent in the usual case of the webserver and the database server being in the same timezone. [...] Often a specific timezone is assumed for displaying date and time. This could very well be incorrect for a large number of visitors. If the database server is in yet another timezone, things begin to get out of sync.

He mentions the time zone functionality that MySQL offers too, but notes that it cannot be relied on either. Thankfully, there's is a bit of hope in PHP5 (as of 5.1 in fact) - the date_default_timezine_set function. He includes an example of the function in use, making it simple to get the correct date and time automatically with the date() function without having to do any hacks to discover the correct time zone.

On his blog today, Joakim Nygard has posted about the use (or disuse) of time zones in PHP:

The problem with not handling timezones correctly is not apparent in the usual case of the webserver and the database server being in the same timezone. [...] Often a specific timezone is assumed for displaying date and time. This could very well be incorrect for a large number of visitors. If the database server is in yet another timezone, things begin to get out of sync.

He mentions the time zone functionality that MySQL offers too, but notes that it cannot be relied on either. Thankfully, there's is a bit of hope in PHP5 (as of 5.1 in fact) - the date_default_timezine_set function. He includes an example of the function in use, making it simple to get the correct date and time automatically with the date() function without having to do any hacks to discover the correct time zone.