WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 3 years ago

Last modified 3 years ago

#10332 closed defect (bug) (fixed)

Backdated pre-1st January 1970 post displayed as published on the current viewing day

Reported by: carboncopy Owned by: nacin
Milestone: 3.2 Priority: high
Severity: major Version: 2.8
Component: Date/Time Keywords: has-patch needs-unit-tests
Focuses: Cc:

Description

When posting a backdated post that is before 1 January 1970, the published on date will show the current viewing date.

The problems starts when posting.

example :

At the New Post interface,

Published On : set to 31 December 1969.
Click published.

The Published On will change to current date.

However, click on Edit, the fields will show the set date (in this example 31 December 1969).

Example :
http://bibliotheca.limkitsiang.com/1969/12/
http://bibliotheca.limkitsiang.com/1970/01/

Attachments (7)

functions.php.diff (655 bytes) - added by gosunatxrea 5 years ago.
added <wp-includes/>
functions.php.2.diff (943 bytes) - added by gosunatxrea 5 years ago.
use version_compare
10332.diff (476 bytes) - added by nacin 4 years ago.
state-diagram.gif (141.2 KB) - added by jdub 4 years ago.
This may come in handy
10332.2.diff (642 bytes) - added by nacin 4 years ago.
Also tries to take into account 32 bit systems. If 1969 does not compute on the system, then it's a PHP < 5.1 issue. Otherwise, if date('U',$t) doesn't match $t, we're looking at a date outside the 32 bit integer limit. (Or a timezone issue? I think we're good there.) Proof of concept and could use some unit tests.
10332.3.diff (719 bytes) - added by DH-Shredder 3 years ago.
Refresh of functions.php.diff (removal of check), since we're standardizing on PHP 5.2.4+ for WP 3.2
Screen shot 2011-05-08 at 18.37.58.png (17.8 KB) - added by westi 3 years ago.
A post from 1969

Download all attachments as: .zip

Change History (49)

comment:1 carboncopy5 years ago

  • Summary changed from Backdated pre-1 January 1970 post displayed as published on the current viewing day to Backdated pre-1st January 1970 post displayed as published on the current viewing day

comment:2 carboncopy5 years ago

  • Milestone changed from Unassigned to 2.8.2
  • Version changed from 2.8 to 2.8.1

comment:3 dd325 years ago

  • Component changed from General to Date/Time
  • Milestone changed from 2.8.2 to Future Release
  • Priority changed from high to normal
  • Version changed from 2.8.1 to 2.8

Setting to Future Release Pending patch.

comment:4 gosunatxrea5 years ago

  • Keywords has-patch added

comment:5 gosunatxrea5 years ago

  • Milestone changed from Future Release to 2.8.3

comment:6 follow-up: dd325 years ago

  • Keywords needs-testing added
  • Milestone changed from 2.8.3 to 2.9

That code block was obviously added as a method to prevent a different bug, Under what situations / server configs has this patch been tested under?

Milestone: Future Release for long-standing defects(ie. are present in many past releases) regardless of patch status, Current-trunk for all other defects, point release back-porting at commiters discretion. (Generic reply for when I change the milestone)

gosunatxrea5 years ago

added <wp-includes/>

gosunatxrea5 years ago

use version_compare

comment:7 gosunatxrea5 years ago

that code block was modified (added) in :
Rev 8199 Fix date() warning on Windows. Props ozh. fixes #7186
Rev 8742 date_i18n() fixes. Props nbachiyski. fixes #8153
Rev 9616 Use localized dates on General Options page. Props nbachiyski. fixes #8153
Rev 9742 date_i18n() fixes. Props nbachiyski. fixes #8153

It is necessary, but
Only when you use 5.1.0-
I think that you have to use that codes.

comment:8 gosunatxrea5 years ago

  • Cc gosun@… added

comment:9 in reply to: ↑ 6 gosunatxrea5 years ago

my environment
Apache 1.3.37
PHP 5.2.5
MySQL 5.1.22-rc

comment:10 follow-up: dd325 years ago

Closed #10780 as duplicate of this.

comment:11 in reply to: ↑ 10 herko5 years ago

a fresh install of 2.8.4 on linux/php 5.2.6 makes it impossible to create content with a date before 1-1-1970, including the slug date values. I tried creating a post dated 1814, and the slug was /1970/1/test. This is WITH the editing out of the code like suggested here: http://core.trac.wordpress.org/attachment/ticket/10332/functions.php.diff.

I tried to verify the bug on another 2.8.4 site, but this one upgraded from 2.3 and onwards,running PHP 5.2.9, with the following results:
Creation of historical content is possible, with the slug created correctly (in this case, /1814/3/test), but the published date shown is the current date (sept 13 2009).
This is without any changes made to functions.php.

So this bug report needs to be reopened.

comment:12 dd325 years ago

  • Keywords dev-feedback added

Looking at #7186, Perhaps we should perhaps use version_compare() w/ a check to see if its linux or windows..

If Windows && PHP older than 5.1.0, Then disable past-dates, Else allow them.

Supports the widest set of servers that way thats possible without causing bugs..

comment:13 gosunatxrea5 years ago

  • Cc gosun@… removed

comment:14 gosunatxrea5 years ago

  • Cc gosunatxrea@… added

comment:15 janeforshort4 years ago

  • Milestone changed from 2.9 to Future Release

Agree this bug should be fixed, but since we're in beta 2 now, punting to next release cycle for further testing and/or revision.

comment:16 gosunatxrea4 years ago

  • Version changed from 2.8 to 2.9.1

comment:17 dd324 years ago

  • Version changed from 2.9.1 to 2.8

gosunatxrea — 110 minutes ago version changed from 2.8 to 2.9.1

Please dont change the Version string on reported bugs, Its the only way of tracking when the bug was introduced. If it exists in an older verison, and the ticket is still open, Its safe to assume it exists in the latest version.

comment:18 herko4 years ago

  • Cc herko added

Now that WP3.0 is in beta 2, this bug will remain open and unsolved, am I correct? Uncommenting the lines 90-98 in wp-includes/functions.php does not work for me.

Symptoms:
[1] When entering a published date prior to 1-1-1970 (european date format), the published date shown in the edit post screen becomes 1-1-1970, but the published date shown when viewing the post itself is the current date. This means that when you view the same post a day later, the published date is a day later then before.
[2] When permalink structure is set to /%year%/%monthnum%/%postname%, all post slugs are /1970/01/postname.
[3] Any reference to the pre-1970 date is no longer shown anywhere.

comment:19 gosunatxrea4 years ago

  • Cc gosunatxrea@… removed

comment:20 ipstenu4 years ago

This still exists in 3.0 RC3.

comment:21 rhoare4 years ago

  • Cc rhoare added

Bug still exists in a clean install of 3.0.1. (Ubuntu Linux 9.10, PHP 5.2.10)

Presumably there are no plans to ever fix it? Does anybody know of a plugin to work around this long-standing bug?

Commenting out just the lines mentioned in function.php no longer fixes it, something else thinks it knows better and comes along and changes the date when you try to save the modified post.

Maybe programmed by somebody aged under 40, who can't imagine there are any dates before they were born. :-)

comment:22 rhoare4 years ago

To correct my above note (which I can't see a way to edit).

Commenting out the lines as given in the fix DO work (so why isn't it in the latest version?).

But only back to 1901. There is a separate bug/feature that makes it impossible to show dates before Dec 14, 1901. Since that is the start of the Unix epoch it's probably rbecause I use a 32-bit OS, I'll try it on a 64-bit server next to see if that helps.

So, just to clarify, the fix shown does work (back to 1901), and should be applied, allowing for the lines being different on the latest version.

comment:23 rhoare4 years ago

After testing, I can still confirm that dates before 1970, back to 1901, work when the bug introduced in 2.8 is commented out.

In addition, to get dates before 1901 you need to use a 64 bit operating system, which has a 64 version of PHP. In my case, it works with 64 bit Ubuntu 9.10 and PHP 5.2.10-2ubuntu6.4. I can modify a post to historical dates (such as 1485), and the date seems to be displayed correctly everywhere so far (including archives) (ignoring Gregorian/Julian calendar changes or old style/new style years, which would really be the job of an extension as it's specialist).

comment:24 nacin4 years ago

  • Milestone changed from Future Release to 3.1
  • Owner set to nacin
  • Status changed from new to reviewing
Before PHP 5.1.0, negative timestamps were not supported under any known version of Windows and some other systems as well. Therefore the range of valid years was limited to 1970 through 2038.

I'm going to see what I can do for this when 3.1 starts up. Going to try to come up with a good test we can do to confirm whether we can use negative timestamps, other than a pure PHP version check. Otherwise I like the idea of a version_check() on the PHP version and only prevent negative timestamps for < 5.1 (which is compatible with how we are doing it now, and allows for a workaround -- upgrading your PHP to get it working) and then dropping the version check in WP 3.2 when we go to 5.2.

nacin4 years ago

comment:25 nacin4 years ago

New patch.

Now we will allow negative timestamps as long as the system supports them. This is detected by taking strtotime() of a date before the Unix epoch. PHP will return -1 on failure until 5.1, at which point this bug is no longer a problem.

Needs sanity testing. Unit tests might be nice. Suggesting commit for 3.1 if this pans out, then we can remove the sanity check for 3.2.

jdub4 years ago

This may come in handy

comment:26 nacin4 years ago

We can probably do a similar check for a date in the year 1900, just outside the 32 bit integer limit, and again force the current timestamp if we're not running on a 64 bit OS.

nacin4 years ago

Also tries to take into account 32 bit systems. If 1969 does not compute on the system, then it's a PHP < 5.1 issue. Otherwise, if date('U',$t) doesn't match $t, we're looking at a date outside the 32 bit integer limit. (Or a timezone issue? I think we're good there.) Proof of concept and could use some unit tests.

comment:27 follow-up: hakre4 years ago

Date time with PHP 5.2 is always 64bit regardless of the underlying OS IIRC. 32Bit system will use a float in PHP then to handle the timestamp. I suggest to upgrade to PHP 5.2 or above to not run into problems.

comment:28 hakre4 years ago

And to not make use of intval();

comment:29 in reply to: ↑ 27 nacin4 years ago

  • Keywords needs-unit-tests added; dev-feedback removed
  • Priority changed from normal to high
  • Status changed from reviewing to accepted

Replying to hakre:

Date time with PHP 5.2 is always 64bit regardless of the underlying OS IIRC. 32Bit system will use a float in PHP then to handle the timestamp. I suggest to upgrade to PHP 5.2 or above to not run into problems.

Correct, and that's reasonable in WP 3.2. But there's a simple interim fix we can do now that will prevent unnecessary limitations in 3.1. The problem is, due to our code right now, upgrading to PHP 5.2 won't produce the desired result -- the code, as is, takes a lowest common denominator approach. Instead of using version_compare(), however, I based this on how PHP handles these values in affected versions, which increases the coverage (as not all < 5.2 versions are affected).

I'm going to try to write some unit tests for this and work on it in 3.1.

comment:30 follow-up: nacin4 years ago

I'll also look into the intval() thing. When I was playing with PHP 4 and PHP 5.3 on a 32bit Windows system, I don't recall seeing that.

comment:31 in reply to: ↑ 30 hakre4 years ago

Replying to nacin:

I'll also look into the intval() thing. When I was playing with PHP 4 and PHP 5.3 on a 32bit Windows system, I don't recall seeing that.

Derick Rethans (author of the lib) reminded me on that detail lately in a talk. So I bet he is right just out of the blue :) . He suggested to use (float) on 32 bit systems.

Internally in the class it's 64 bit regardless of the system setting. At least that's how I have understood him.

comment:33 nacin3 years ago

  • Keywords 3.2-early added
  • Milestone changed from 3.1 to Future Release

We'll have PHP 5.2 available in 3.2. Let's do this then and be done with it.

comment:34 nacin3 years ago

  • Milestone changed from Future Release to 3.2

Closed #17126 as a duplicate.

DH-Shredder3 years ago

Refresh of functions.php.diff (removal of check), since we're standardizing on PHP 5.2.4+ for WP 3.2

comment:35 DH-Shredder3 years ago

  • Cc DH-Shredder added

Since even on 32bit Windows (PHP 5.2.4 and 5.3.5), the date works properly with the appropriate check removed, do we still need to do the special check?

Tested, and PHP 5.2.4 and 5.3.5 are both outputting proper str2time() negative output even under 32bit.

Attached a refreshed patch, in case we want to just get rid of the check altogether.

comment:36 nacin3 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

(In [17747]) Remove PHP 5.1/Windows code from date_i18n. Allows timestamps from pre-1970. props DH-Shredder, fixes #10332.

comment:37 westi3 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:38 westi3 years ago

Removing all that code broke this function - See #17278.

We just needed to remove the negative number check to remove the backcompat.

I suspect that this is still fixed but it needs testing.

westi3 years ago

A post from 1969

comment:39 westi3 years ago

http://core.trac.wordpress.org/attachment/ticket/10332/Screen%20shot%202011-05-08%20at%2018.37.58.png

Pre-1970 dates work for me.

Closing as fixed.

Version 0, edited 3 years ago by westi (next)

comment:40 westi3 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

comment:41 westi3 years ago

  • Keywords needs-testing 3.2-early removed

comment:42 carboncopy3 years ago

Yes! Finally. Thanks for the work on it. :)

Example : http://bibliotheca.limkitsiang.com/1969/01/

Note: See TracTickets for help on using tickets.