[Zope3-dev] Re: SVN: Zope3/branches/3.3/ Fixed issue 525: DateWidget ru-format

[Dmitry Vasiliev]

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 (http://mail.zope.org/pipermail/zope3-dev/2006-June/019585.html) 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 hlabs.spb.ru)
     http://hlabs.spb.ru