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.