Gary Poster wrote:

However, I'm not sure the new widget behavior is great for non-default locales either. Certainly being able to display dates in a locale-specific way is nice, but the input seems to be problematic. If you specify an ACCEPT-LANGUAGE of "en-US", for instance, you need to fill in "Dec 2, 2002 12:30:00 PM", if I remember correctly. Fully spelling out "December" does not work. Leaving off the seconds doesn't work. Any other format will not work. I didn't check, but assume other languages result in similar restrictions in input.

Yes, the input is a bit problematic in russian too, especially for "long" and "full" display styles. Unfortunately I didn't get any reply on my pre-checkin message ( so I guessed no one was interested in the problem.

The data in en.xml could be usable to get a more robust approach, and it could even be done without change to zope.i18n for dates. But AFAICT, for datetimes some help would need to be implemented in the i18n.locale module (since the order of dates and times is specified in the XML); and for datetimes and times I think we'd want to make specifying seconds, and maybe even minutes, optional. This is probably doable, but it seems like it might be painful to code and test.

I agree the i18n datetime parsing should be made a bit relaxed. I even think the only important thing in this context is the order of the fields, so we can ignore spaces (or even ignore some other delimitters?) and maybe ignore other non-field characters (for example in the russian "long" format you always need to write year as "year 2006" instead of the simple "2006").

I understand what Dmitry did, and why he did it. It makes sense theoretically, but seems to fall down a bit practically. I wonder if this should be an optional set of date and datetime widgets, rather than the default ones.

I think we just need to relax a bit i18n datetime parsing and the widgets will be useful as is. BTW, shouldn't we add Time and Timedelta widgets?

I think I've heard that the parsing in the old datetime widget was Ameri-centric, but at least it could handle an ISO standard that was unambiguous, defensible, and easily described in some static "how to specify a date" example or instructions.

It would be useful if some sort of instruction with the desired input format will appears for the datetime fields, for example as dynamic description of the field.

The other approach is for someone to spend some time polishing the i18n.locale formatting code a bit. That won't solve the test problem ('2005 4 12 12:15:00 ') but it would at least make the primary user experience more reasonable.

I don't think we need to change the formatting code, just need to make the parsing code a bit flexible. I can start working on the parsing code if no one objects.

BTW, maybe we need to do something with timezone offset-naive/offset-aware datetime issue? For example we can store all time in UTC and convert it as needed on input/output (it's like unicode for time :), or just store offset-naive time as UTC. It seems currently we don't have a consistent policy for this case.

Dmitry Vasiliev (dima at
Zope3-dev mailing list

Reply via email to