Ticket #2149 (assigned defect)

Opened 3 years ago

Last modified 4 months ago

Historical Dates (Pre 1901) Unsupported in Wordpress

Reported by: wiseburn Assigned to: pishmishy (accepted)
Priority: normal Milestone: 2.9
Component: General Version: 1.5.2
Severity: normal Keywords: has-patch dev-feedback
Cc:

Description

Reference: http://wordpress.org/support/topic/53061

Wordpress relies on the PHP date() and time() functions for most date/time processing. This limits wordpress's ability to handle dates outside the valid range of a timestamp [typically from Fri, 13 Dec 1901 20:45:54 GMT to Tue, 19 Jan 2038 03:14:07 GMT. (These are the dates that correspond to the minimum and maximum values for a 32-bit signed integer). However, before PHP 5.1 this range was limited from 01-01-1970 to 19-01-2038 on some systems (e.g. Windows).]

Wordpress should be able to handle any date, including dates outside this range. This is needed for entering historical data.

Separate variables for Year, day of year, and time of day will handle any date. (other choices will work equally well)

Using the adodb_date_library http://wordpress.org/support/topic/27367#post-194153 as a workaround has worked for some, but I'm still having trouble with dates before 1900.

e.g. http://danielcady.com/letters/ A post dated Sept 2, 1812 is displayed as September 9th, 1948 (The permalink doesn't work either)

MT supports dates outside the range 1901-2038

Dates in Wordpress should not be limited to the range of the intrinsic php functions based on a 32bit value. (Note that MySQL does not store the time and date in a 32bit signed integer and does not have a problem with dates before 1901 or after 2038)

Attachments

2149.patch (1.6 kB) - added by pishmishy on 03/14/08 09:24:16.
Preliminary patch
2149-post.php.patch (1.6 kB) - added by pishmishy on 03/14/08 13:43:45.
Extra validation of date input

Change History

12/25/05 22:10:10 changed by ryan

  • milestone set to 2.1.

12/30/05 14:55:29 changed by davidhouse

  • priority changed from normal to low.

10/03/06 23:44:51 changed by Nazgul

  • keywords set to needs-patch.
  • milestone changed from 2.1 to 2.2.

I don't see this happening in 2.1, but a valid candidate for 2.2.

03/27/07 02:35:49 changed by foolswisdom

  • milestone changed from 2.2 to 2.4.

06/01/07 15:04:50 changed by Nazgul

  • status changed from new to closed.
  • resolution set to wontfix.
  • milestone deleted.

No traction for over a year, so closing as wontfix.

Feel free to reopen if you have patches/suggestions/...

03/11/08 20:38:40 changed by mark8barnes

  • status changed from closed to reopened.
  • resolution deleted.

This is actually a problem. In 2.5 I accidentally changed the year of a post to "200" rather than "2008". The post virtual disappeared. None of the permalinks to it worked, and it couldn't be found by searching or sorting on date. Even if WP won't support very old dates, it at least needs to modify its error handling.

03/11/08 20:57:17 changed by lloydbudd

  • milestone set to 2.6.

03/13/08 15:37:27 changed by pishmishy

  • owner changed from anonymous to pishmishy.
  • status changed from reopened to new.

03/13/08 15:53:26 changed by pishmishy

  • status changed from new to assigned.

Changing a recent post to the year 200, post_date appears to be being set correctly (0200-03-13 15:38:27) but post_date_gmt appears to be incorrect (1969-12-31 23:59:59).

03/13/08 16:06:34 changed by pishmishy

Problem lies with use of gmmktime() and gmdate() in formatting.php's get_gmt_from_date() and get_date_from_gmt() which accept only a 32-bit signed timestamp as input.

03/13/08 16:37:13 changed by pishmishy

  • keywords changed from needs-patch to needs-patch dev-feedback.

The range of dates covered by the 32-bit integer don't overlap with MySQL's ISO8601-like format. There's no easy way to reconcile this problem with PHP (unless we wish to write our own library for handling dates). What we could do is an SQL statement such as 

mysql> select '1869-01-02 12:34:56' - INTERVAL 7 HOUR;
+-----------------------------------------+
| '1869-01-02 12:34:56' - INTERVAL 7 HOUR |
+-----------------------------------------+
| 1869-01-02 05:34:56                     | 
+-----------------------------------------+

I don't like adding unnecessary database queries but I think this is only going to get called when posts, pages or comments are created so it shouldn't cause too much overhead.

03/14/08 09:24:16 changed by pishmishy

  • attachment 2149.patch added.

Preliminary patch

03/14/08 09:29:07 changed by pishmishy

Extra coding is needed to disallow storage of dates outside of '1000-01-01 00:00:00' to '9999-12-31 23:59:59' (in practice disallowing input of dates outside of '1000-01-01 12:00:00' to '9999-12-31 12:00:00' if we take into account our manipulation of the data)

03/14/08 13:43:45 changed by pishmishy

  • attachment 2149-post.php.patch added.

Extra validation of date input

03/14/08 13:48:21 changed by pishmishy

  • keywords changed from needs-patch dev-feedback to has-patch dev-feedback.

2149-post.php shows extra validation of datetime input. An adjusted version of this patch should still be used even if we decide not to allow MySQL's entire range of dates.

mysql2date() and current_time() need patching if we go down the MySQL route.

Thoughts... would it be easier to use PEAR's Date package?

05/06/08 09:51:16 changed by pishmishy

  • priority changed from low to normal.
  • type changed from enhancement to defect.

With the lack of any feedback I say we go for the simple approach of adding extra validation. I'm changing the lack of proper validation of acceptable input as a defect rather than an enhancement.