Make WordPress Core

Opened 10 years ago

Closed 6 years ago

Last modified 6 years ago

#2149 closed defect (bug) (wontfix)

Historical Dates (Pre 1901) Unsupported in Wordpress

Reported by: wiseburn Owned by: pishmishy
Milestone: Priority: normal
Severity: normal Version: 1.5.2
Component: Date/Time Keywords: needs-patch dev-feedback
Focuses: Cc:


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

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 (2)

2149.patch (1.6 KB) - added by pishmishy 8 years ago.
Preliminary patch
2149-post.php.patch (1.6 KB) - added by pishmishy 8 years ago.
Extra validation of date input

Download all attachments as: .zip

Change History (19)

#1 @ryan
10 years ago

  • Milestone set to 2.1

#2 @davidhouse
10 years ago

  • Priority changed from normal to low

#3 @Nazgul
9 years ago

  • Keywords needs-patch added
  • Milestone changed from 2.1 to 2.2

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

#4 @foolswisdom
9 years ago

  • Milestone changed from 2.2 to 2.4

#5 @Nazgul
8 years ago

  • Milestone 2.4 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

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

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

#6 @mark8barnes
8 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

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.

#7 @lloydbudd
8 years ago

  • Milestone set to 2.6

#8 @pishmishy
8 years ago

  • Owner changed from anonymous to pishmishy
  • Status changed from reopened to new

#9 @pishmishy
8 years ago

  • 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).

#10 @pishmishy
8 years ago

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.

#11 @pishmishy
8 years ago

  • Keywords dev-feedback added

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.

8 years ago

Preliminary patch

#12 @pishmishy
8 years ago

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)

8 years ago

Extra validation of date input

#13 @pishmishy
8 years ago

  • Keywords has-patch added; needs-patch removed

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?

#14 @pishmishy
8 years ago

  • 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.

#15 @Denis-de-Bernardy
7 years ago

  • Keywords needs-patch added; has-patch removed

patch needs an update...

#16 @Denis-de-Bernardy
7 years ago

  • Component changed from General to Date/Time

#17 @Denis-de-Bernardy
6 years ago

  • Milestone 2.9 deleted
  • Resolution set to wontfix
  • Status changed from accepted to closed
Note: See TracTickets for help on using tickets.