Add the deform.widget.DateTimeWidget widget, which uses the jQueryUI Timepicker add-on.

[dnouri]

DateTimeWidget uses the ISO8601 combined date and time format
internally, as expected by colander.DateTime, but converts to the
more friendly separate date and time format for display in the widget.

[dnouri]

Let me know if I can help get this merged. If it were my birthday, I'd also wish for a new release. I have a package that's already depending on these changes. :-)

https://github.com/dnouri/kotti_calendar

[oO]

I just did something similar to a local branch. I have however created new types as well, called SimpleTime and SimpleDateTime, that strip the seconds and milliseconds.

The rationale is that any user facing data doesn't need that kind of precision. Imagine if you had a form to book a flight, and the date time widget asked you to fill in seconds?

I'm also looking into a javascript-based date-range validator, that would enforce start < end.

[dnouri]

I'd rather keep using the datetime.date and datetime.datetime types because there's wide support for them. And worry about the user interface in the widget. The Timepicker add-on that I'm using here doesn't let you set seconds anyway.

[mcdonc]

This patch looks great. Unfortunately, the DateTime widget, while it works fine in Firefox 3, does not seem to work in Chromium. Could I tweak you into maybe testing/fixing that?

[mcdonc]

I should clarify "doesn't work"... no matter what input you provide to the widget in Chromium, it won't allow you to submit, claiming "Invalid value".

[dnouri]

You're right. I think I need to use the datetime-local input type instead and stick to the somewhat cryptic combined ISO format. I was pretty naive about using input type="datetime".

http://dev.w3.org/html5/markup/input.datetime-local.html

[dnouri]

I experimented with input type="datetime-local", but that's

• using yet another format (combined with "T") where leaving out seconds is valid, which iso8601.py doesn't like,
• not playing nicely with the jQuery widget so we'd have to not activate the widget when browser support for datetime-local exists, which would leave us with a very crude interface in Chrome where you only get +/- controls for minutes, and no calendar.

[mcdonc]

OK, I think without full features in IE, Chrome, FF this probably belongs in an add-on unless there's some way to get it all to go.

[dnouri]

Well I implemented it with input type="text" and it seems to work fine everywhere. So this can go in unless you insist we use the HTML5 datetime-local input type.

[mcdonc]

Nope, no insistence here.. just let me know what to do.

[oO]

I would go with text. I'm happy to be HTML5 compliant, but only when it doesn't break HTML4+ while doing so. I think the datetime stuff falls in that category.

[dnouri]

Hehe. So this last commit 7028e90 fixes the problem that you were seeing. I realise I might have confused you with my "I experimented with..." comment. Thanks.

[mcdonc]

Rock on. Merged.