Make WordPress Core

Opened 11 years ago

Closed 5 years ago

#22194 closed defect (bug) (wontfix)

PHP x64 compatibility issue with date values

Reported by: whissi's profile Whissi Owned by: pento's profile pento
Milestone: Priority: normal
Severity: normal Version:
Component: Date/Time Keywords:
Focuses: Cc:

Description

Hi,

seems like WordPress is using the "0000-00-00 00:00:00" value as magic value for date values, which aren't set instead of NULL.

This is working fine for any PHP x86 builds, because the magic value is also an invalid date.

But PHP x64 builds support this value. It is no longer invalid. It is now a valid date! This will result in problems, because some functions are expecting that parsing this date will return false, but now on x64 systems they won't get an invalid date, when they are expecting one.

So the problem is, that WordPress is using a valid date as magic value for an invalid date aka default value.

Fixing this issue will require a SQL schema change and to update all the code, checking for "0000-00-00 00:00:00"...

For references, see ticket #21987 and https://bugs.php.net/bug.php?id=53662

Change History (4)

#1 @SergeyBiryukov
11 years ago

  • Component changed from General to Date/Time

#2 @chriscct7
9 years ago

  • Keywords dev-feedback needs-patch added
  • Owner set to pento
  • Severity changed from major to normal
  • Status changed from new to assigned

#3 @pbearne
8 years ago

yes is going to touch a lot of code

Are we going to "fix" the schema and set null for no date?

or

test for 64bit system and then look for ????

strtotime("0000-00-00 00:00:00") returns FALSE on a 32 bit system.
strtotime("0000-00-00 00:00:00") returns -62169955200 on a 64 bit system.

#4 @Rarst
5 years ago

  • Keywords dev-feedback needs-patch removed
  • Resolution set to wontfix
  • Status changed from assigned to closed

Unfortunately I don't think it will be possible to change schema for this. It's effectively public API and who knows how those fields are used in the wild and what assumptions they are making about possible values.

We can (and definitely will) improve how this is handled through API if any issues bite. I will probably jinx it, but it's been years and nothing exploded too horribly about it. Now it probably will tomorrow!

Note: See TracTickets for help on using tickets.