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.

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

The time-zone database (sometimes referred to as the Olson database) is the computing world's principle source of time-zone data. It is embedded in every Unix and Java for starters, and will be used by many websites and probably by your iPhone. You may know it via the IDs, such as "Europe/London" or "America/New_York". But, perhaps you're thinking that time-zones don't change? Well that may be true for America and the EU right now, but certainly isn't for the rest of the world.

Astrolabe claims that the database is a part of the work on their "ACS Atlas" product and the contents of it belong to them.

The impact of this is severe for anyone that uses it - whether via Java, Unix or some other means. This really is the key tool used by everyone to tell the right time globally. We all owe a debt of gratitude to the database maintainers who have worked on this for many, many years at zero cost to the industry and for zero financial gain.

Stephen puts out a call to some of the larger technology leaders/companies to help resolve this situation and/or provide a resource where this information can once again be accessed freely.

I really like Doctrines way of dealing with dates and times. Instead of passing timestamps around or strings with ISO date format it simply makes use of the PHP native type DateTime which provides all you really need to work with. PHPs interface to MongoDB however comes with its own MongoDate type which provides hardly any functionality compared to DateTime and it's not compatible with it. So what's the difference?

In some of the comments to the post, readers mention that the problem is bigger than just the tools used to work with the database, it's that databases usually don't care about timezones when working with date/time. There's also an interesting mention further down about the timezone support MongoDB does have and an example snippet ofo code that uses the support.

A lot of people ask questions relating to date and time in PHP. Here are some answers to the most commonly asked questions and common mistakes.

He covers the differences between working with dates in strtotime, worrying about timezone settings and compares the strtotime/DateTime methods for formatting and returning dates, modifying dates, converting between timezones as well as finding the difference between two timezones.

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

In the newer PHP 5.3 versions even more excellent functionality was added. This is a short post to introduce this functionality with a focus on the methods available in PHP 5.2 showing some simple examples of how we can more easily manipulate and display dates without needing to work with timestamps.

She shows how to create a simple DateTime object, how to change up the timezone information related to it and has an example of how to output the format with a call to the format function. She also mentions how they can simplify the storage of date information in a database since they can be moved around between timezones easily (instead of having to calculate the different between where it was created and where it's being used).

In this example, we get or set dates in different timezones. We display parts of dates and times in various formats. We also get information on sunrise and sunset in several locations.

They also incorporate other components in the examples including Zend_Cache, Zend_Locate and Zend_Registry. Their examples show how to check the locale, verify the timezone and figure out a "date from now". Complete code is included - it's not the best method to handle some parts of the example, but it's a rough guide in the right direction.

I was recently tasked with building an application that relied heavily on accurate time zone conversions. I, like many people I soon found out, thought there were just a handful of timezones and the usual select list would suffice. The deeper I looked into the problem, the deeper it got: the list above only shows a few time offsets from UTC, but it doesn't tell me, beyond a shadow of a doubt, exactly what time it is where the user is situated, nor can I rely on that time for calculations in the future. The fact is, here are a LOT of timezones in the world.

He came across the DateTimeZone class PHP has to offer and was happy to see it met his needs. Unfortunately, users weren't always sure what timezone they were in, so he came up with a system combining Google's Maps API and GeoNames.org. He includes the code for both the PHP and Javascript sides (the Javascript requires Mootools, but it could be easily adapted to any other Javascript libraries).

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