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.

I've seen a lot of newbies (and not newbies) having problems handling dates in PHP (and even with SQL and another languages). When I see someone having problems with dates, I always ask the same question. I type in a text editor "27/11/2012″ and I ask him: What is it? If your answer is "This is a date" you should continue reading the post.

He talks about how the DateTime functionality replaces (much more effectively) some of the older date handling methods in PHP. He includes a few examples comparing it to date and showing how it can be used to compare dates. He includes a "Dummy" class he mocked up to show how you could work with DateTime to get/set formatted dates, set the format to use and get the current format. As always, he also provides tests for the code as well.

This is just the tip of the iceberg as to what DateTime can do, so I'd suggest checking out the manual page for it to see the full list of features.

DateTime is nothing new, but it's definitely under-used by many. It was made available in PHP 5.2.0 but got some of its best features until PHP 5.3.0. PHP 5.3.0 is pretty old now, but I learned about DateFormat::createFromFormat() after reading a new addition to PHP The Right Way: Date and Time.

He shares to "offender" examples where using this function allowed him to simplify and reduce the amount of code needed to handle the formatting of a date into a MySQL format and calculating the difference between two time values.

The solution we hit on was to leverage Doctrine's system of event listeners to help us do the work. Doctrine allows you to register listeners with the entity manager that are called whenever certain events occur. We created an event listener that is triggered on the onFlush event.

Code is included for the event listener they created - a simple "onFlush" event that grabs the current entities from the manager, sets the date/time property to allow it to be changed (via Reflection) and updating it with the new cleaned format.

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

When working in any programming language, dealing with dates and time is often a trivial and simple task. That is, until time zones have to be supported. Fortunately, PHP has one of the most potent set of date/time tools that help you deal with all sorts of time-related issues: Unix timestamps, formatting dates for human consumption, displaying times with time zones, the difference between now and the second Tuesday of next month, etc. In this article I'll introduce you to the basics of PHP's time functions (time(), mktime(), and date()) and their object-oriented counterparts, and then take a look at MySQL dates and show you how to make them play nicely with PHP.

His examples include how to get the current Unix time, formatting dates/times, making timestamps and working with the more powerful DateTime objects. On the MySQL front, he shows the result of a normal date select, one using the "unix_timestamp" function and how to shift the result based on the user's timezone.

As part of a recent project, I was tasked with taking timestamps returned by an API and displaying fuzzy dates in the final output (e.g. 3hrs ago, in 2 weeks, tomorrow). The timestamp format in question looks like: 2012-09-01T16:20:01-05:00 This format can be found in PHP as the DATE_ATOM or DateTime::ATOM constants, which contain the date() formatter string: Y-m-dTH:i:sP With this in hand, we can now easily parse the timestamp into a useful object.

Parsing the date into a DateTime object is as easy as giving it the date string and telling it how it's formatted. Then you can do all sorts of fun things. He shows how to shift the timezone by name, by time increment - simple (like "1 hour") and more complex (like "1 hour 5 minutes 3 seconds"). You can find out more about the DateTime object in the PHP manual.

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.

Date and time manipulation in PHP is mostly connected with functions like: date, time or strtotime. They can be sufficient, but if we want to deal with dates like with objects - we can use DateTime class. DateTime class is not only straightforward wrapper for standard functions, it has a lot of additional features - for example timezones.

He shows how to use the DateTime functionality to return an object you can call several different methods on. He gives examples of the formatting call, comparing one DateTime object to another, how to update the date after the object's created, calculating the difference between two dates and iterating through a certain time period.

Y2K38, or the Unix Millennium Bug, affects PHP and many other languages and systems which use a signed 32-bit integer to signify dates as the number of seconds since 00:00:00 UTC on 1 January 1970. The furthest date which can be stored is 03:14:07 UTC on 19 January 2038. Beyond that, the left-most bit is set and the integer becomes a negative decimal number or a time prior to the epoch.

If you're worried about your application's support for date and time handling, there's a pretty simple fix - replace your current handling with the DateTime functionality. This handles them correctly.