Fix for CRM 19881: Clobbered time for receive_date and trxn_date

[h-c-c]

https://issues.civicrm.org/jira/browse/CRM-19881

Unlike api.contribute.create, api.contribute.repeattransaction and completetransaction zero out the time stamp in parameters receive_date and trxn_date respectively.

What api.contribution.create shows in receive_date is something like:
2017-01-14 16:10:45

However, what api.contribution.repeattransaction shows in receive_date is something like:
2017-01-14 00:00:00

This is because the specification is:
'type' => CRM_Utils_Type::T_DATE,
Instead of:
'type' => CRM_Utils_Type::T_DATE + CRM_Utils_Type::T_TIME,

Same issue for completetransaction and it's trxn_date parameter.

[civicrm-builder]

Can one of the admins verify this patch?

[totten]

jenkins, ok to test

[h-c-c]

@totten Jenkins is so mad at me. :P This branch was such a cluster, since it was based on the wrong branch. Should I just close this and start over? Thanks

[totten]

@h-c-c , yeah -- if the original work was based on a very different branch or has "merge commits", I usually find it easier to start-over (and maybe try git cherry-pick or git cherry-pick --no-commit).

Personally... if my starting branch is fairly close but has one conflict... then I tend to update PR's using git rebase instead, e.g.

git fetch origin
git rebase -i origin/master

The neat thing is that it gives some chance to edit/combine/discard your changes. However, if you do a rebase, then you also need a force push, as in:

git push -f h-c-c CRM-19881

[h-c-c]

Thanks so much @totten! I rebased and forcefully pushed.

Can I enlist jenkins? or do you have to?

[totten]

Hopefully neither of us need to. ;) Once the PR or author is approved, any updates to the PR will automatically trigger a re-test in Jenkins.

[eileenmcnaughton]

This is just a (sensible) change to the field definition, approving

[h-c-c]

Thanks!