mysql2date() limitation for scheduled posts

[nofearinc]

The latest ​Theme Unit Test data is ​available here for theme reviewers (and theme developers) to test against.

There is a post scheduled for year 2050. During the import process in wp_insert_post there is this snippet:

    } elseif( 'future' == $post_status ) {
                $now = gmdate('Y-m-d H:i:59');
              if ( mysql2date('U', $post_date_gmt, false) <= mysql2date('U', $now, false) )
                      $post_status = 'publish';

mysql2date uses strtotime and the future date could return false which would update the status of the future post to publish.

This is probably related to the date limitation for 32-bit systems, as described ​on php.net:

    The valid range of a timestamp is typically from Fri, 13 Dec 1901
 20:45:54 UTC to Tue, 19 Jan 2038 03:14:07 UTC. (These are the dates
 that correspond to the minimum and maximum values for a 32-bit
 signed integer.)

Since that's still fine given the current date, it might be a minor issue, but it's being exposed in a use case such as the import process where a future post is being published instead while migrating to another site.

For that specific use case scenario adding a non-false check would help, but is probably an overhead:

if ( false !== mysql2date('U', $post_date_gmt, false) && mysql2date('U', $post_date_gmt, false) <= mysql2date('U', $now, false) )

[SergeyBiryukov]

Introduced in [14062].

[nofearinc]

The Theme Reviewers team updated the ​Test data to 2020 to avoid issues until this one is resolved in some way.

[chriscct7]

The year 2038 problem is going to come up more and more.

[Rarst]

Changed to string comparison to not depend on int range and added unit test.

[SergeyBiryukov]

In 45851:

Date/Time: In wp_insert_post(), when checking the post date to set future or publish status, use string comparison to work around far future dates (year 2038+) on 32-bit systems.

Props Rarst, nofearinc.
Fixes #25347.

[SergeyBiryukov]

In 45852:

Coding Standards: Fix WPCS violations in [45851].

See #25347.