Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
wp_date roadmap #1
This is the initiative to fix up and improve Date/Time component of WordPress core.
This issue will be a living document of challenges, goals, and work in progress.
Date/Time core component was developed in PHP 4 language. It predates much of upstream PHP
At a certain point it went through a partial PHP 5 retrofit. It added a new timezone functionality, more reliant on PHP funcitonality. However the old custom timezone implementation is still in active use.
In current state the component has a lot of major bugs and interoperability issues with PHP.
The outstanding problems with the component fall into three categories.
Code and documentation bugs
Due to the age and complexity of the component there a lot of issues with incorrect operation of code. On top of that the subtle and layered mechanics of it in many case come with incorrect documentation.
This type of issues needs direct fixes.
Implementation design issues
The component has many custom design decisions. That leads to complication in use and unreliable operation.
The most prominent examples are:
Design issues are unfixable. Any functional change to adjust behavior would break backwards compatibility and downstream code.
This type of issues needs to removed from the code base (if possible) or deprecated.
User experience issues
Internal implementation and external API complexity make the component a challenge to use.
Many operations lead to incorrect output of time information for humans and machines. This has negative implications in many areas:
The project aims to improve the Date/Time component for three major groups of users:
The main risks are backwards compatibility and lack of access to modern PHP.
One of the main challenges is older timezone implementation. It is both in active use and requires large amounts of custom implementation code.
It is unclear to which degree design challenges can be fixed. Initial stages of the project will increase clarity about the state of the component.
At the moment I (Rarst) volunteer my time to organize and develop the project. There is a risk of stall if my availability changes. I am looking for sponsors to be able to focus on the project and reduce this risk, but it will go ahead regardless.
Without wanting to be picky: I'd rather not "adjust time data storage and operations to canonical use of UTC".
Having said all that I'd happily contribute to bringing the best possible DateTime-handling class to WordPress!
That is not what currently happens though. Currently what is stored by WordPress is a time with unknown time zone. Even if we add time zone separately it would be impractically complicated to use in SQL queries, which are currently broken for edge cases, unless ordering by GMT field is explicitly requested.
There would definitely be some discussion on this (feel free to open issue yourself!), but personally I don't see a way forward other than making UTC time canonical. What we have now is a disaster and there are very few ways ahead due to backwards compatibility limitations.
The timezone shouldn't be unknown as all DateTimes are created with the currently set default timezone and timestamps are always per definition UTC.
As the main Backend is MySQL it should be possible to implement a way to order dates using SQL like the following for sorting by UTC:
SELECT * FROM table ORDER BY CONVERT_TZ(myDateTime, myTimezone, 'UTC')
I'd definitely be interested in the edge cases!
Though timezone-handling will definitely be interesting on outdated systems. As soon as the timezone-database is not updated regularily on the PHP and on the MySQL-side all that effort is useless. There might be a way to handle timezones purely in PHP but that would still leave the MySQL-side…
But still I'd rather not recommend converting DateTimes to UTC/timestamps due to changes to the timezone-database between the conversion of the DateTime to UTC and the actual DateTime as those will result in wrong Informations being stored…