How to Count Days Between Dates in PHP: 5 Fatal Mistakes

"How many days have passed?" — a question that trips up beginners

Every PHP developer sooner or later faces the task: you need to find out how many days have passed between two dates. It seems simple, right? Take two strings, subtract one from the other — and you're done. But it's right here, out of the blue, that the most insidious mistakes are made.

We looked at Stack Overflow and found a real question, "Finding the number of days between two dates," which has gathered thousands of views. It turns out that even experienced programmers fall into traps related to time zones, Unix timestamps, and the unexpected behavior of strtotime().

In this article, we'll break down the five most common mistakes when calculating the number of days between dates in PHP and show you how to avoid them. Get your editor ready — there will be plenty of code and practical advice.

Mistake #1: Subtracting Unix timestamps "directly"

The most popular mistake is trying to get the difference between dates by simply subtracting timestamps:

<?php\n$date1 = strtotime('2024-01-01');\n$date2 = strtotime('2024-01-10');\n$days = ($date2 - $date1) / (60 * 60 * 24);\necho $days; // 9\n?>

On the surface, it works. But try switching the clocks to daylight saving time. When moving to "summer time," the day shortens by an hour, and when moving back, it lengthens. The result: 9.04166 or 8.95833 days instead of exactly 9.

How to fix it

Use DateTime objects and the diff() method. They account for all time jumps:

<?php\n$date1 = new DateTime('2024-01-01');\n$date2 = new DateTime('2024-01-10');\n$interval = $date1->diff($date2);\necho $interval->days; // 9 — always correct\n?>

Working with date difference in PHP via DateTime::diff is the industry standard. Remember this pattern.

Mistake #2: Ignoring the time zone

Imagine: your server is located in Europe/Moscow, and a user from New York enters the date "2024-03-10". You create a DateTime without specifying a time zone. PHP uses the server's system timezone. The result: the difference in days can "drift" by one.

This is especially critical at month boundaries and during daylight saving time transitions. The error appears rarely, but when it pops up in production, it's very hard to catch.

Solution: explicitly set the time zone

<?php\n$tz = new DateTimeZone('UTC');\n$date1 = new DateTime('2024-03-10', $tz);\n$date2 = new DateTime('2024-03-20', $tz);\n$interval = $date1->diff($date2);\necho $interval->days; // 10 — honest\n?>

Always use UTC for internal calculations. If you need to show the date to the user, convert it to their local time zone only at the output stage.

Mistake #3: Confusing days and format('%a')

The DateInterval object has a days property and a format('%a') method. It seems like they are the same thing. But there's a nuance:

\n
• $interval->days — the total number of days (accounts for all months and years). The value is always correct.
\n
• $interval->format('%a') — the same thing, but as a string.
\n
• $interval->d — only the days without accounting for months. If the difference is 35 days, then d will return 4 (the remainder after subtracting a month).
\n

Beginners often confuse d and days. As a result, they get 4 days instead of 35. This leads to bugs in reports, billing, and task schedulers.

Always check which property you are using

<?php\n$date1 = new DateTime('2024-01-01');\n$date2 = new DateTime('2024-02-05');\n$interval = $date1->diff($date2);\n\necho $interval->days; // 35\necho $interval->d;    // 4 — NOT THE SAME!\n?>

If you need exactly the number of days between two dates — take