The DateTime class sure has some handy methods and seems overall superior to the native PHP date functions like strtotime, mktime and strftime (and more). But is there any drawback or a reason why I shouldn't use it ?

The only reason I can think of is that it might be more expensive to create a whole instance of a class than just using a function.

  • Would you agree with that ?
  • Does it make sense at all to use a DateTime object for simple stuff?
  • Are there any other drawbacks ?

It seems a bit confusing to switch between those two options all the time, so I'd like to have clearance what I should prefer doing.

Two examples for my decision would be:

  • Converting a date to a localized value
  • Calculating the time between two dates

If your worry is that creating a class instance is expensive and that it'll hinder performance, then I'm afraid you're barking at the wrong tree. One should never consider whether to use proven OO approach where it makes sense. If it makes sense to use DateTime class in order to perform certain date calculations, then use it. It's not expensive to the point where your app will feel it, unless you do something crazy such as creating 1 million DateTime objects.

Reason why DateTime is great is because it alleviates the worry of daylight savings by specifying the time zone when creating the object. It's also easy to obtain differences between dates or obtain intervals between different objects. It basically cuts down the amount of worry and coding required (but I will admit it is wrong sometimes, hopefully it'll get addressed in 5.4 release of PHP).

Bottom line - I'd always use it.


For the record, I did the mistake to use the class DateTime. It was a big mistake. While it has some nice features, but it is not worth the effort. I explain:

Let's say that you have a form (with a date-picker) and you are storing into the database, then you have 3 formats to represent the date.

  1. Internally, the variable is of the type DateTime()
  2. Visually, the variable displayed to the user is a string of the format dd-mm-yyyy or mm-dd-yyyy (it depends on the regional setting)
  3. In the database, the variable stored is also a string of the format yyyy-mm-dd (ANSI)

So, I am dealing with 3 different kinds of representation for the same type of data

Also, let's say that you want to serialize (json, xml or such), it is the serialization:

object(stdClass)#1 (1) {
  object(DateTime)#2 (3) {
    string(26) "2018-12-02 09:14:09.216273"
    string(30) "America/Argentina/Buenos_Aires"

It is a real pain to try to serialize. My alternative is simple, to store any temporal date as a string and I will convert it to DateTime only if it's needing.

object(stdClass)#3 (1) {
  string(19) "2018-12-02 09:14:09"
  • 1
    I completely agree that it requires much work to have DateTime on a business layer. In cases where it is worth it, I recommend to use different models for different layers. My view models have strings for dates, while I am working with DateTime on business layer. I can recommend AutomapperPlus to map the entities between layers. Good interface and support. Required only in complex cases, of course. – Vitalii Isaenko Mar 8 at 13:25
  • I think you're not in a better place by not using DateTime object because regardless you always have to consider those 3 layers: 1. How information is used in the code (OOP) 2. How information is stored in the database (DB native data type) 3. How information is displayed/presented to end user (formatting) – Online Sid Apr 3 at 23:07
  • Isn't that exactly the benefit of using DateTime though? By dealing with an abstract representation of the date, you're always free to format() it for the case at hand. Usually, any object I'm going to serialize to JSON implements the JsonSerializable interface, so I can format any date properties to RFC date strings. For the database, I'll use ANSI dates, and so on - it's really less painful than having to cast from and to timestamps everywhere... – Moritz Friedrich Apr 24 at 8:57
  • In your example, if you are not storing timezone with your string, it will not work if your application is used in different timezones. – Shaunak Sontakke May 2 at 16:51
  • And it is exactly the point. Let's say 10:15 AM StandardPacific Hour (GMT-8) and our system work globally. Then, let's say we want to read it under GMT-3, we we should read the 10:15 (gmt-8), then convert it to gtm-3 and show it as a local hour. The solution is to save it ZULU / GMT-0 (Greenwich) time, so the conversion is easy and we don't need to save the timezone – magallanes May 2 at 20:27

Using DateTime() makes the code more readable compared to the procedural approach of strtotime(), etc. functions.

if( strtotime( date( 'm/d/Y', strtotime( $strStartDate ) ) ) > strtotime( date( 'm/d/Y', strtotime( '+6 month', strtotime( $strEndDate ) ) ) ) ) {


if( new DateTime( $strStartDate ) > ( new DateTime( $strEndDate ) )->modify( '+6 month' ) ) {

On Windows 64 bit development machines, PHP is still 32bit. It will give your weird results for dates beyond Fri, 13 Dec 1901 20:45:54 UTC to Tue, 19 Jan 2038 03:14:07 UTC

echo ( new DateTime( '20 Jan 2038' ) )->format( 'm/d/Y' ) . PHP_EOL; // gives 01/20/2038
echo strtotime( '20 Jan 2038' ); // returns false


Note: The valid range of a timestamp is typically from Fri, 13 Dec 1901 20:45:54 UTC to Tue, 19 Jan 2038 03:14:07 UTC. (These are the dates that correspond to the minimum and maximum values for a 32-bit signed integer.) Prior to PHP 5.1.0, not all platforms support negative timestamps, therefore your date range may be limited to no earlier than the Unix epoch. This means that e.g. dates prior to Jan 1, 1970 will not work on Windows, some Linux distributions, and a few other operating systems. For 64-bit versions of PHP, the valid range of a timestamp is effectively infinite, as 64 bits can represent approximately 293 billion years in either direction.

I am not sure if daylight saving is properly handled with native date time functions.

I would recommend using DateTime() functions over native date time functions.

Your Answer

