Make WordPress Core

Opened 18 years ago

Closed 14 years ago

Last modified 14 years ago

#2149 closed defect (bug) (wontfix)

Historical Dates (Pre 1901) Unsupported in Wordpress

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



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 as a workaround has worked for some, but I'm still having trouble with dates before 1900.

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 16 years ago.
Preliminary patch
2149-post.php.patch (1.6 KB) - added by pishmishy 16 years ago.
Extra validation of date input

Download all attachments as: .zip

Change History (19)

#1 @ryan
18 years ago

  • Milestone set to 2.1

#2 @davidhouse
18 years ago

  • Priority changed from normal to low

#3 @Nazgul
17 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
17 years ago

  • Milestone changed from 2.2 to 2.4

#5 @Nazgul
16 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
16 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
16 years ago

  • Milestone set to 2.6

#8 @pishmishy
16 years ago

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

#9 @pishmishy
16 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
16 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
16 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.

16 years ago

Preliminary patch

#12 @pishmishy
16 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)

16 years ago

Extra validation of date input

#13 @pishmishy
16 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
15 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
14 years ago

  • Keywords needs-patch added; has-patch removed

patch needs an update...

#16 @Denis-de-Bernardy
14 years ago

  • Component changed from General to Date/Time

#17 @Denis-de-Bernardy
14 years ago

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