Long-Needed Date/Time Improvements Land in Core

Decorative close-up image of an old pocket watch.

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.

Would you like to write for WP Tavern? We are always accepting guest posts from the community and are looking for new contributors. Get in touch with us and let's discuss your ideas.

6 Comments


  1. I am not a developer and I want to thank the ones who work hard to clean WP code. Most of the bad reviews I read about WP were relative to his code and I’m glad to read such news.

    Report


  2. Tremendous work. Thank you Rarst.

    Report


  3. Wow! So glad this was seen and so much work done sifting through these rabbit holes! Huge thanks!

    I was looking into doing something with timestamp related stuff just yesterday –

    Hoping to get some code put together that will basically:

    find post_last_modified_time, If post_last_modified_time less-than 12 hours ago, show post_featured_image, else show standard-too-late-image

    With the new api hooks in next release, I wonder if that kind of code would be best / easiest / fastest to execute using the unix machine time I am guessing?

    Report


    1. Yep, the new `get_post_timestamp()` will easily give you a true Unix timestamp (it will have an argument for modified time) and comparing it to `time()` the difference in seconds.

      Still waiting for new functions to be scanned into documentation, will happen closer to WP 5.3 release. :)

      Report

Comments are closed.