Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wp_date roadmap #1

Open
Rarst opened this Issue Jun 21, 2018 · 5 comments

Comments

2 participants
@Rarst
Copy link
Owner

Rarst commented Jun 21, 2018

Welcome to wp_date!

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.

Current situation

Date/Time core component was developed in PHP 4 language. It predates much of upstream PHP DateTime functionality. It was also written to make exclusive use of WP’s own localization functionality for the output.

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.

Challenges

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:

  • storage of local time without timezone information
  • custom timezone math in old implementation
  • use of custom timestamps, incompatible with general convention

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:

  • end–user experience
  • programming interoperability
  • communication over REST API
  • SEO
  • and so on.

Goals

The project aims to improve the Date/Time component for three major groups of users:

  1. For site owners — to remove the problems in normal site operations and use of WP extensions.
  2. For developers — to improve quality of API. Make implementation more reliable and PHP development easier.
  3. For platform users — to improve reliability. Fix time data storage, its access and operation. Communication with other systems on PHP and REST API levels.

Risks

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.

Channels

  • this repository — for ongoing development work and broad planning
  • core trac — for individual issues and submitting completed patches
  • slack #core-datetime — for discussions and tracking what needs merges

Actions

References

@Rarst Rarst self-assigned this Jun 21, 2018

@Rarst Rarst added the organization label Jun 21, 2018

@heiglandreas

This comment has been minimized.

Copy link

heiglandreas commented Jun 21, 2018

Without wanting to be picky: I'd rather not "adjust time data storage and operations to canonical use of UTC".
I've written a blogpost about why not to convert to UTC and as far as I see it the possibilities for DateTimes in WordPress are given that they do not always only represent information within the next two weeks from "now". Therefore I'd rather keep the current approach of storing a DateTime and a Timezone. That's also what I usually suggest in my Timezone-Talk

Having said all that I'd happily contribute to bringing the best possible DateTime-handling class to WordPress!

@Rarst

This comment has been minimized.

Copy link
Owner Author

Rarst commented Jun 21, 2018

Therefore I'd rather keep the current approach of storing a DateTime and a Timezone.

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.

@heiglandreas

This comment has been minimized.

Copy link

heiglandreas commented Jun 21, 2018

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…

@Rarst

This comment has been minimized.

Copy link
Owner Author

Rarst commented Jun 21, 2018

New issue if you want to continue discussion please. :)

@Rarst Rarst added this to In progress in wp_date Jun 28, 2018

@Rarst Rarst pinned this issue Dec 14, 2018

@Rarst

This comment has been minimized.

Copy link
Owner Author

Rarst commented Jan 7, 2019

If WP does indeed bump minimum PHP version to 5.6 this spring that will hugely simplify a lot of issues in Date/Time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.