DateTime class vs. native PHP date-functions

Question

The DateTime class sure has some handy methods and seems overall superior to the native PHP date functions like strtotime, mktime and strftim

Answer 1

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

vs

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

https://www.php.net/manual/en/function.strtotime.php#refsect1-function.strtotime-notes

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.

Answer 2

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.

Answer 3

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) {
  ["field1"]=>
  object(DateTime)#2 (3) {
    ["date"]=>
    string(26) "2018-12-02 09:14:09.216273"
    ["timezone_type"]=>
    int(3)
    ["timezone"]=>
    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) {
  ["field1"]=>
  string(19) "2018-12-02 09:14:09"
}