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

[carboncopy]

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/

[dd32]

Setting to Future Release Pending patch.

[dd32]

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)

[gosunatxrea]

added <wp-includes/>

[gosunatxrea]

use version_compare

[gosunatxrea]

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.

[gosunatxrea]

my environment
Apache 1.3.37
PHP 5.2.5
MySQL 5.1.22-rc

[dd32]

Closed #10780 as duplicate of this.

[herko]

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.

[dd32]

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

[janeforshort]

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.

[dd32]

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.

[herko]

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.

[ipstenu]

This still exists in 3.0 RC3.

[rhoare]

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

[rhoare]

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.

[rhoare]

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

[nacin]

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.

[nacin]

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.

[jdub]

This may come in handy

[nacin]

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.

[nacin]

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.

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

[hakre]

And to not make use of intval();

[nacin]

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.

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

[hakre]

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.

[hakre]

X-Ref: #14889

[nacin]

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

[nacin]

Closed #17126 as a duplicate.

[kirasong]

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

[kirasong]

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.

[nacin]

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

[westi]

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.

[westi]

A post from 1969

[westi]

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

[carboncopy]

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

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