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.

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.

This is short post to address a frustration I've seen mentioned on Twitter and in forums a lot: By default, the SQL Server Driver for PHP returns datetime columns as PHP DateTime objects, not strings. This can be especially frustrating if you are not aware of the ReturnDatesAsStrings connection option. By simply setting this option to 1 (or true) when you connect to the server, datetime columns will be returned as strings.

He includes some sample code showing how to use the setting (as a part of the settings array passed in to sqlsrv_connect) and the resulting array key from the fetched results on his sample table. This just gives you one more option for handling dates in your SQL Server-based application, especially if you don't need the full DateTIme object's functionality.

PHP has made some progress here as well, for example with the Standard Php Library and its interfaces. Though, the SPL is incomplete and oriented to performance more than to object-oriented programming: take a look at the SplStack and SplQueue implementation containing 20 different methods to get the idea. However a little gem is shipped with each PHP installation: the datetime extension, which contains the DateTime class and its siblings. Ideally, everything you can do with date_* functions, you can do it with this class.

He includes some code that shows the DateTime object in action as a part of a PHPUnit test case - adding days, subtracting months, date difference and its support of operator overloading. There's also mention of Doctrine's native support for the extension.

I don't want to be too alarmist, but try running the [given] PHP code on your system. [...] With luck, you'll see "Wednesday 1 February 2040 00:00" displayed in your browser. If you're seeing a date in the late 60's or early 70's, your PHP application may be at risk from the Y2K38 bug!

The bug, caused by a 32-bit operating system, can be helped by running the application on a 64-bit platform (it's due to the limitation of integer size), but there is another option - the DateTime class that handles dates and times differently than the just using the local time settings.