OOPS registering sprint or meeting using date format DD-M-YYYY

[Diogo Matsubara]

Steps to reproduce (using sample data):
1. Open http://launchpad.dev/sprints/+new
2. Fill in all required fields;
3. Fill in "Starting date and time": 15-5-2008
4. Fill in "Finishing date and time": 16-5-2008
5. OOPS-598S557 IntegrityError ERROR: new row for relation "sprint" violates check constraint "sprint_starts_before_ends"

Recently: OOPS-980S229, OOPS-980S233, OOPS-980S236

[Diogo Matsubara (matsubara)]

I seem to be wrong in my assumption that the cause of the bug is the date format: DD-M-YYYY
This bug can also be reproduced using the same date and time for both steps 3 and 4 in the following format YYYY-MM-DD HH:MM:SS
A similar oops (OOPS-600A1612) can be seen in the sprint attendence form (i.e. $sprint/+attend). I suspect that the problem lies in the LocalDateTimeWidget.

[Jonathan Knowles (jsk)]

I have confirmed this OOPS when using the DD-M-YYYY
So far I've been unable to confirm that the bug occurs when using the YYYY-MM-DD HH:MM:SS format.

[Jonathan Knowles (jsk)]

This is caused indirectly by bug 139360 in Zope 3.2.

[Jonathan Knowles (jsk)]

Bug 139360 in Zope's DateTimeParser causes certain dates to be parsed incorrectly. In the example given above, both dates are parsed incorrectly to the same date: 1st January 2008. Since meetings must finish after they start (in our database), the above integrity error is triggered.

[Jonathan Knowles (jsk)]

Shifting to 1.1.10 as the fix is non-trivial. We need to apply a temporary workaround for bug 139360.

[Jonathan Knowles (jsk)]

Also raised a further related bug 139413 (LocalDateTimeWidget doesn't support little-endian dates).

[Jonathan Knowles (jsk)]

Resetting to confirmed after discussion at Malone Sprint.

[Jonathan Knowles (jsk)]

Resetting to confirmed after discussion with BjornT.

[Curtis Hovey (sinzui)]

We have a new datetime widget that handle user mistakes better.

[j.c.sackett (jcsackett)]

The largest problem here isn't in the field; by the time data makes it to the field, it's already been formatted. The problem is that zope.datetime.parse can only deal with "%Y-%m-%d" and "%m-%d-%Y" dates. Further, it requires dates to be double-digit, so that '5' there throws it completely for a loop and it comes up with 2008-1-1 for both.

When *that* happens, the code for validating the data in the view correctly determines that the start_date isn't later than the end_date (they're the same) but our database sees start as greater.

[Launchpad QA Bot (lpqabot)]

Fixed in stable r12434 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/12434>.