Unix epoch is not accepted in date field values [Has Patch]

[francescolaffi]

either in registration or edit profile date fields unix time epoch (1-1-1970) is said to be invalid / not processed. 0 is a valid strtotime return value, but the validation code check every field with empty() so it says it is not valid.

patching should be easy, I'll upload diff soon

[francescolaffi]

proposed patch

[cnorris23]

So are you saying that you're entering "0" as the date, instead of "1-1-1970"?

[francescolaffi]

I'm selecting 1 jan 1970 from the dropdown fields in registration or edit profile page, then the core convert it to a timestamp with strtotime function for better handling and storing in the db. The problem is that the timestamp of 1-1-1970 is 0 and the core validate all values with empty function, so 0 is not accepted.

[cnorris23]

Ah, I see. I thought you were saying you were entering 0, which would be a fringe case. This is definitely a problem since it's basically saying you couldn't have possibly been born that day :). From your patch, it looks like tested this on BP trunk. Is this also an issue in the 1.2.x branch?

[francescolaffi]

Yes also 1.2 branch has this issue. If a dev set the milestone to 1.2.4 the patch can be easily changed for that.

[cnorris23]

I would go ahead and update the patch for the 1.2.x branch, and set the milestone for 1.2.4. The devs can punt it if they don't feel it should go in.

[DJPaul]

Patch needs updating and issue confirming in trunk.

[francescolaffi]

Ok I'll update it

[boonebgorges]

What if we just stored the date in 2010-11-23 20:04:25 type format instead of in unix seconds? That seems easier than trying to write replacements for core PHP functions like empty()

[francescolaffi]

Replying to boonebgorges:

What if we just stored the date in 2010-11-23 20:04:25 type format instead of in unix seconds? That seems easier than trying to write replacements for core PHP functions like empty()

@boone: Yep that sound a good solution
With regret I remove myself as owner, this year in uni is more difficult than expected and I'll not have time to write another patch :(

[r-a-y]

Also see #2963.

[cnorris23]

Related #2947

[cnorris23]

Per boone's suggestion I've changed the date from a Unix time stamp to a MySQL time stamp. I've added in some backwards compatibility for existing Unix timestamps, and some minor comment cleanup. The succeeding patch was made to work with #2947.

[cnorris23]

Made to work with #2947. Otherwise replace $date with $field->data->value

[cnorris23]

This patch needs updating based on changes in [3651]. This is more for me, so I'll remember to update the patch... hopefully tonight.

[cnorris23]

Patch updated for current trunk.

[boonebgorges]

Bringing to 1.5 since there's a patch, though I reserve the right to punt!

[cnorris23]

Haha! It's been a while since the patch was refreshed, so unless you beat me to it, I'll take a look at it tonight.

[cnorris23]

Updated for current trunk

[r-a-y]

Confirmed that this issue still exists.

I think the easiest solution is to convert the value to date() as cnorris23 has it in bp-xprofile-screens.php.

006.patch adds this same logic to bp-members-signup.php.

[cnorris23]

Updated patch to include bp-members-signup.php instances.

[r-a-y]

Good catch on the other strtotime reference in bp-members-signup.php, cnorris23.
Was a late night!

[boonebgorges]

(In [5131]) Switches date picker xprofile fields to save in MySQL date format rather than UNIX timestamp, to prevent problems with UNIX epoch. Fixes #2240. Props cnorris23, r-a-y