Evert Pot has a new post sharing some of the changes in DateTime handling that he's updated in the latest release in the PHP 5.5.x series.

PHP 5.5.10 got released a few weeks ago, and among other things, it added some new functionality related to timezone handling. In short, [subtracting from UTC] now works. Normally this would not be recommended, as you really should specify timezones based on their geographical location. This information is not always available though, so it's a welcome new feature.

Other changes include the removal of the automatic translation from "UTC" to "GMT" as well as errors being thrown when one of the "odd" timezones are used (he provides the list). Additionally, an update around timezone "guessing" has been added and the fallback that was in place has been removed.

On the Websanova.com site there's a recent post about doing timezones the right way when working with them in PHP and storing them in your (MySQL) database.

Timezones are actually a very trivial concept but they seem to be overlooked and over complicated. [...] Rather than storing a timezone with each date it’s better to just accept a standard time to store all your dates with, thus doing the conversion to that standard time before storing the value in the database. It doesn’t really matter what time we store it as, but it’s generally a good idea to just use UTC+00:00.

They talk a little about what the UTC timezone is for those that may not know and show how to set it as the default timezone for your PHP application (with date_default_timezone_set or updating your php.ini). They also include the MySQL configuration option to set its default timezone and and example SELECT statement for extracting the data back out.

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").

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.

Based on a fix for a recent bug, Derick Rethans wanted to clear up something about the Unix Epoc's definition and how it relates to the UTC time zone.

While right now it is proper to define the Unix Epoch at "1970-01-01 00:00:00 UTC", UTC wasn't actually defined until 1972. So it would be more correct to define the Unix Epoch as "the number of seconds elapsed since midnight proleptic Coordinated Universal Time (UTC) of January 1, 1970, not counting leap seconds." (from Wikipedia).

He talks about the calendar PHP uses internally and how dates predating it's use don't make much sense either (as well as the modified version PHP uses that includes "year zero").

Derick Rethans one of the go-to guys for working with time in PHP has made this new post about something 2008 picked up along the way to 2009 - a leap second.

The start of this new year started with some buzz about a leap second being introduced between Dec 31st 2008, 23:59:59 and Jan 1st 2009, 00:00:00. I've had people ask where this leap second actually comes from, and whether you need to worry about it in your applications. To understand leap seconds means, unfortunately, understanding how time is actually kept.

He ponints out one of the major problems - how time is kept. With variants of Universal Time, it makes it hard to track down what's "right". He breaks out the difference between other time storage methods and the unix time that PHP can use (that counts the number of seconds since Jan 1st 1970) and how the leap second was handled for each.

Derick Rethans one of the go-to guys for working with time in PHP has made this new post about something 2008 picked up along the way to 2009 - a leap second.

The start of this new year started with some buzz about a leap second being introduced between Dec 31st 2008, 23:59:59 and Jan 1st 2009, 00:00:00. I've had people ask where this leap second actually comes from, and whether you need to worry about it in your applications. To understand leap seconds means, unfortunately, understanding how time is actually kept.

He ponints out one of the major problems - how time is kept. With variants of Universal Time, it makes it hard to track down what's "right". He breaks out the difference between other time storage methods and the unix time that PHP can use (that counts the number of seconds since Jan 1st 1970) and how the leap second was handled for each.