'dd/mm/yy' date format issue in v3.4.1 in memberships

[Luciano S.]

Hi,

I've upgraded recently from v3.3.3 to v3.4.1 and I am facing an issue creating/editing a membership. (was working ok in 3.3.3)
My civicrm site is configured with 'dd/mm/yy' date format.

I'll try to explain what I get, and my research trying to find where the bug is:

when creating a membership, I set member since and start date fields and the error I get in validator is:
"There is no valid Membership Status available for selected membership dates."
that was weird, cause the dates are ok. Anyway I can skip this Overriding the Status

I go on..

when editing a membeship the errors I get:
"Start date must be set if end date is set."
"End date must be the same or later than start date."
..etc that was weird again.. cause the dates are ok, and with correct format. Anyway I can skip this selecting for instance 01/01/2011 for all dates

I go on..

After editing (only editing, creating put the correct dates I selected) I saw when I choose a date with a day grater than 12, the date that it's saved in the DB it's January 1st, 1970


mmmm, my research in the source code:

Basically the problem is how it's parsing the date format internally. And it's different when creates and edits the membership
in CRM_Member_Form_Membership class, function postProcess(),  line 734

I echo the variable $formValues with tha values coming from the Form for create and edit a membership:


New Membership

Code: [Select]

Array
(
    . . .
    [join_date] => 06/21/2011
    [start_date] => 06/23/2011
   . . .
)
Edit Membership

Code: [Select]

Array
(
    . . .
    [join_date] => 21/06/2011
    [start_date] => 23/06/2011
)
first big issue, the values of join_date, start_date, end_date are coming in 'mm/dd/yy' in the form post when creating and in 'dd/mm/yy' format when editing.

Later in the process the function CRM_Utils_Date::processDate() is used.
If you pass this function a date in dd/mm/yy format with a day greater than 12, it returns 19700101010000 (January 1st, 1970)

Comparing this function between versions I saw that it changed in 3.4.1
This part of code is missing in line 1319, and it was in the v3.3.3

Code: [Select]

if ( $inputFormat == 'dd/mm/yy' ) {
              $date = str_replace( '/', '-', $date );
}
from php.net

Note:

Dates in the m/d/y or d-m-y formats are disambiguated by looking at the separator between the various components: if the separator is a slash (/), then the American m/d/y is assumed; whereas if the separator is a dash (-) or a dot (.), then the European d-m-y format is assumed.

but adding that source code again in the  CRM_Utils_Date::processDate() wasn't a solution, because the date is past as argument in different formats. Depends if it's editing or creating a membership.

I cannot find where the format of the values in textbox are set.


Well, I hope I was clear.
I've created an issue
http://issues.civicrm.org/jira/browse/CRM-8244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=36390#action_36390

sorry if this post is too long, I tried to be as clear as possible.
Any help is more than welcome, because basically the CiviMember module is not working at all due to this issue

thanks very much!
luciano

[Luciano S.]

Steps to reproduce this bug in the sandbox demo site.

1. Administer / Configure / Global Settings / Date Formats. Set 'dd/mm/yy' format


2. Create New Membership, set Member Since Date something like '25/05/2011' (day grater than 12). Same for Start Date. Save
This error msg will be displayed (it shouldn't):
There is no valid Membership Status available for selected membership dates.


3. To skip this error check Status Override, and select one Status. Save
Everything seems to be saved right


4. Edit that membership. Select again dates with day greater than 12. Save
You'll see the dates now are saved as January 1st, 1970

[Dave Greenberg]

luciano - thx for the detailed debugging on this. I've also recreated the issue and escalated it on the issue tracker. Both CREATE and EDIT are mis-handling that input date format. Keep on eye on the issue tracker issue for updates - we'll probably want you to grab a patch and QA it on your site.

[Luciano S.]

Thanks Dave,

looking forwards for that patch, and of course I will QA it and give you the feedback

[Dave Greenberg]

Luciano - I've tested the latest fix on this (from svn) and tentatively closed the issue. However it would be helpful if you can grab a patch from the issue tracker (should be available from Fisheye tab later today or tomorrow).

http://issues.civicrm.org/jira/browse/CRM-8244

[Martin Fuggle]

We are experiencing the same issue (obviously) and it makes our production site problematic especially since we have just emailed all our members asking them to update their details including their birth date where we are seeing the same problem.  Is there a patch available yet?

Cheers
Martin Fuggle

[Dave Greenberg]

Pick up the two diffs on first panel of fisheye tab on the issue, should do it:
http://issues.civicrm.org/jira/browse/CRM-8244?page=com.atlassian.jira.ext.fisheye%3Afisheye-issuepanel

i.e.
http://fisheye2.atlassian.com/viewrep/CiviCRM/branches/v3.4/CRM/Utils/Date.php?r1=34059&r2=34728
http://fisheye2.atlassian.com/viewrep/CiviCRM/branches/v3.4/templates/CRM/common/jcalendar.tpl?r1=34064&r2=34728

[Loster]

Just upgraded to 3.4.3 and this fixed this issue for me...

Thanks very much all for highlighting and for patching...

Loster