Long-Needed Date/Time Improvements Land in Core

After more than a year and several WordPress updates, an overhaul of the core Date/Time component concluded. WordPress 5.3 will ship with fixes for long-standing bugs and new API functions.

Andrey “Rarst” Savchenko spearheaded this project and worked through most of the issues in his WP Date fork of WordPress. Much of his work toward addressing the problems with this core component goes back further with the initialization of his WPDateTime project.

Diving into the Date/Time component is no small feat. Addressing one issue leads to another. It’s a rabbit hole that few in the community have navigated. Many developers were also unaware of the issues. However, the bugs lingered for years, and users had no working solution for the problems they were facing.

The most common errors were caused by core bugs or developer errors due to compatibility issues, described Savchenko. This would cause user-facing issues such as post scheduling and other time-based operations.

With the release of WordPress 5.3, all existing functions should behave more reliably. Developers working on the component fixed several bugs and updated incorrect inline code documentation for many core functions. Along with the fixes, 5.3 will ship with new Date/Time API functions. The updated API includes unified time zone retrieval, localization, and PHP interoperability functions.

Savchenko called it “the slow descent into madness” when asked of the catalyst for diving into the Date/Time component and its underlying issues. “I started to notice serious bugs in the component from WordPress Stack Exchange questions about them, and the more I looked over years the more clear the dire state of it became to me.”

One of the major problems is the way WordPress handles timestamps. “I actually had to invent the ‘WordPress timestamp’ term,” said Savchenko. “There was no name for it in core development and inline documentation incorrectly called these Unix timestamps before.” WordPress adds a time zone offset to the real Unix timestamp, which causes issues with upstream PHP and external systems.

WordPress timestamps couldn’t be removed from core without breaking backward compatibility. Plugin and theme developers should avoid working with the WordPress timestamp and opt to use the recommended methods outlined in Savchenko’s post.

WordPress date functions were originally written in PHP 4, a version of PHP so long-dead that it’s almost not worth digging up the end-of-life date (it’s 11 years, by the way). PHP 5.2 introduced the PHP DateTime and DateTimeZone classes and has continued receiving improvements over the years. WordPress date functions were never updated to utilize newer standards. The platform’s more recent bump to a minimum of PHP 5.6 also meant that the DateTimeImmutable class introduced in PHP 5.5 would be available. The version bump helped land the new API functions in WordPress 5.3.

Some bugs go as far back as 7 years, such as shorthand formats not working with the core date_i18n() function, which was fixed in WordPress 5.1. With any luck, core may also adopt such features as user-based timezones in the future, which would better handle time differences on WordPress installs with users all over the world.