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
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
