In this new post to his site, Derick Rethans shows an instance of "GMT being tricky" when it comes to "UTC" versus "GMT" output from PHP's DateTime object.

Earlier today, on twitter, @skoop asked: "dear #lazyweb, when I use DateTimeZone('GMT'), why does format('e') output UTC?" [...] As you can see [the example with a format of "e" on a DateTimeZone('GMT')] has UTC and not GMT as you might expect.

Derick mentions that sometimes, systems require "GMT" instead of "UTC" in the output they're given. To work around this issue, he shows how to add a "type 2" timezone to the DateTime object by including it when you initialize the object (code samples included). Using alternative methods, you can add these "type 2" timezones in three ways - an offset in the initial string, using the abbreviation (like "EST" or "PST") and specifying the long version of the timezone (like "America/Montreal").

In this quick new post to his blog Mark Story talks about two new errors he ran across when upgrading his installation to PHP 5.4, both showing up under E_ALL.

I've been running the PHP5.4 RC builds for the last few months, and there are some interesting changes in the upcoming PHP release. On top of all the great new features coming in PHP5.4. After updating to PHP5.4-RC4, a few things that used to not trigger errors and silently do the wrong thing, now trigger notices or warnings.

The two he mentions deal with a new warning on illegal string offsets and the other about string offsets ("Notice: String offset cast occurred"). You can find out about more changes in the PHP 5.4 series in the various Changelogs for each Release Candidate and beta release.

In a new post to the SitePoint PHP blog today Craig Buckler looks at a method for synchronizing your time between your PHP application and it's MySQL backend to make date handling a bit easier - no messy code-based timezone changes needed.

Many developers solve the problem by shifting all date/time responsibility to PHP. They may also convert dates to Unix timestamp integers for simpler handling, although you should be wary of the Y2K38 Bug.

They show a handy tip so you won't have to worry quite so much that relies on setting a "TIMEZONE" constant you can use to set the default timezone and a "time_zone" offset that can be used each time you make the connection to your database (or, alternatively, in a cron that keeps things up to date without interfering with performance).

Derick Rethans has a new post to his blog that helps to demystify some of the confusion around storing dates correctly in your application's database. He mentions a suggested method of using the UTC time and offset together, but talks about why this isn't the best alternative.

After my talk during ConFoo on Advanced Date/Time Handling I received a question about whether the UTC-offset, together with the date/time in years, months, days, hours, minutes and seconds, was enough for storing a date/time in a database and still being able to do calculations with this. The answer to this question was no, but it lead to an even more interesting discussion about what would be enough to store an accurate date/time in a database.

He mentions the main issue with the UTC-offset method - time changes like Daylight Saving throwing a wrench into the works and how adding/subtracting hours doesn't always work as expected. His suggestion is to store the actual DateTime object information representing the location in question, the timezone identifier and the date/time information as strings. Then, when you need to calculate the date information on the other side, you can recreate it with a DateTime and DateTimeZone objects.

On the Builder.com.au website today, there's a quick new tutorial on grabbing the correct time for a user's "home" rather than the server's time.

PHP comes with an extensive catalog of date and time functions, all designed to let you easily retrieve temporal information, massage it into a format you require, and either use it in a calculation or display it to the user. However, if you'd like to do something more complicated, things get much, much hairier

To make things easier, they enlist the service of the PEAR Date package to help bridge the gap between the time zones faster. They give some of the basics of using the package before actually getting into the time zone conversion. The code is pretty straight-forward and they even include other simple tips like how to calculate the GMT offset and how to add and subtract timespans.

On the Builder.com website, there's a new tutorial demonstrating how to use the PEAR Date class to make switching between time zones a snap.

To be fair, PHP has built-in time zone functions to help with this, but these aren't particularly intuitive and require a fair amount of time to get used to. A quicker alternative is to use the PEAR Date class, which comes with built-in support for time zones and is, by far, the simplest way to perform these conversions.

This tutorial will teach you how to convert temporal values between time zones with the PEAR Date class. It assumes that you have a working Apache and PHP installation and that the PEAR Date class has been correctly installed.

They go with a few simple examples to introduce you to how things work:

• just taking in and echoing back out the date
• taking in the date and echoing it back out in a different format
• making a simple time zone conversion
• convert the timestamp to local time
• finding the offset for the time stamp from GMT
• adding and subtracting time stamps