Re: [Zope3-dev] Re: SVN: Zope3/branches/3.3/ Fixed issue 525: DateWidget ru-format
Christian Theune wrote: Dmitry Vasiliev wrote: 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'm very much against relaxed date/time format checking. I tend to give my user the exact format that is expected and fail otherwise. All the guessing in the past led to bad bad errors because the field order the user entered was syntactically compatible but had a semantically different meaning. E.g. 02/05/2005 and 02.05.2005 are two different things. Relaxed doesn't mean try to parse any possible datetime format in the world. For each locale the ICU XML files contains 4 date formats and 4 time formats. The formats mainly useful for formatting printable datetime representation and a bit strict for parsing. So there are my ideas: - it would be useful if DateTimeFormat (hmm, maybe also NumberFormat) might to parse any format combination for the current locale (if it possible) in some unstrict mode; - I think it would be safe to parse any number of space characters as one space character and ignore literal (quoted in the pattern) characters on input; - I think it would be safe to interchange long and short month names on input (as Gary already pointed); -- 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
Re: [Zope3-dev] Re: SVN: Zope3/branches/3.3/ Fixed issue 525: DateWidget ru-format
Dmitry Vasiliev wrote: 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'm very much against relaxed date/time format checking. I tend to give my user the exact format that is expected and fail otherwise. All the guessing in the past led to bad bad errors because the field order the user entered was syntactically compatible but had a semantically different meaning. E.g. 02/05/2005 and 02.05.2005 are two different things. Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: SVN: Zope3/branches/3.3/ Fixed issue 525: DateWidget ru-format
Wichert Akkerman wrote: Previously Christian Theune wrote: I'm very much against relaxed date/time format checking. I tend to give my user the exact format that is expected and fail otherwise. All the guessing in the past led to bad bad errors because the field order the user entered was syntactically compatible but had a semantically different meaning. Shouldn't users use a nice dynamic widget to select dates and times? That will prevent all these problems. Hell no. :) It's much more efficient for a trained user to type '2005-08-08' instead of having to click for 2 minutes through a usable nice widget. BTW: The best UI I ever worked with was an ASCII terminal-software where one should select menu entries by typing their numbers. I could blindfoldedly navigate through that system much faster than most of the software I use today ... Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: SVN: Zope3/branches/3.3/ Fixed issue 525: DateWidget ru-format
On Wed, Jun 28, 2006 at 11:47:28AM +0200, Christian Theune wrote:
I'm very much against relaxed date/time format checking. I tend to
give my user the exact format that is expected and fail otherwise. All
the guessing in the past led to bad bad errors because the field order
the user entered was syntactically compatible but had a semantically
different meaning.
E.g.
02/05/2005 and 02.05.2005 are two different things.
As another data point, I recently stumbled on this quirk
of zope 2's DateTime class:
DateTime('2006/01/01').timezone()
'US/Eastern'
DateTime('2006/01/01').timeTime()
1136091600.0
DateTime('2006-01-01').timezone()
'GMT+0'
DateTime('2006-01-01').timeTime()
1136073600.0
AFAICT, this is a feature, not a bug.
--
Paul Winkler
http://www.slinkp.com
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: SVN: Zope3/branches/3.3/ Fixed issue 525: DateWidget ru-format
Tres Seaver wrote: Dmitry Vasiliev wrote: It's the datetime format for the default locale, see the specification in zope/i18n/locales/data/root.xml. That breaks a test: File /home/tseaver/projects/Zope-CVS/tseaver-retire_zpkg-2.10/lib/python/zope/formlib/form.txt, line 1547, in form.txt Failed example: print MyAddForm(None, request)() # doctest: +NORMALIZE_WHITESPACE Expected: input class=textType id=form.now name=form.now size=20 type=text value=2002-12-02 12:30:00 / Got: input class=textType id=form.now name=form.now size=20 type=text value=2002 12 2 12:30:00 / You just need to update your zope.formlib package. The test was fixed in the original checkin. -- 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
Re: [Zope3-dev] Re: SVN: Zope3/branches/3.3/ Fixed issue 525: DateWidget ru-format
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
[Zope3-dev] Re: SVN: Zope3/branches/3.3/ Fixed issue 525: DateWidget ru-format
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dmitry Vasiliev wrote: Benji York wrote: Philipp von Weitershausen wrote: Dmitry Vasiliev wrote: Log message for revision 68818: Fixed issue 525: DateWidget ru-format - type=text value=2002-12-02 12:30:00 / + type=text value=2002 12 2 12:30:00 / Note that a EditForm can't make use of a get_rendered method. The get_rendered method does only set initial values. Why does the display of the default DateTime widget change? DatetimeWidget now use zope.i18n for parse and format values so the display is the same as for DatetimeDisplayWidget (note the line 1529 of the form.txt). ...and in such a strange way? It's the datetime format for the default locale, see the specification in zope/i18n/locales/data/root.xml. That breaks a test: File /home/tseaver/projects/Zope-CVS/tseaver-retire_zpkg-2.10/lib/python/zope/formlib/form.txt, line 1547, in form.txt Failed example: print MyAddForm(None, request)() # doctest: +NORMALIZE_WHITESPACE Expected: input class=textType id=form.identifier name=form.identifier size=10 type=text value= / input class=textType id=form.name name=form.name size=20 type=text value= / input class=textType id=form.min_size name=form.min_size size=10 type=text value= / input class=textType id=form.max_size name=form.max_size size=10 type=text value= / input class=textType id=form.now name=form.now size=20 type=text value=2002-12-02 12:30:00 / Got: input class=textType id=form.identifier name=form.identifier size=10 type=text value= / input class=textType id=form.name name=form.name size=20 type=text value= / input class=textType id=form.min_size name=form.min_size size=10 type=text value= / input class=textType id=form.max_size name=form.max_size size=10 type=text value= / input class=textType id=form.now name=form.now size=20 type=text value=2002 12 2 12:30:00 / not onlyt that, but I don't believe that '2002 12 2 12:30:00' is a valid date representation in *any* standard locale. The dashes-with-leading-zeros should be the default (it is the stock ISO date format). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEoE23+gerLs4ltQ4RAj8JAJ0WzmZFOqNm1Fi2wRuOiGSIR3DwiACfXvEB BeY9EW5FqiOAAiRpXJlmWwo= =KV4D -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: SVN: Zope3/branches/3.3/ Fixed issue 525: DateWidget ru-format
On Monday 26 June 2006 17:12, Tres Seaver wrote: not onlyt that, but I don't believe that '2002 12 2 12:30:00' is a valid date representation in *any* standard locale. The dashes-with-leading-zeros should be the default (it is the stock ISO date format). This has nothing to do with an ISO. IT is simply the format ICU chose as the default, maybe exactly because it is not a real one. The test failure should be fixed. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: SVN: Zope3/branches/3.3/ Fixed issue 525: DateWidget ru-format
On Jun 26, 2006, at 5:12 PM, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dmitry Vasiliev wrote:
Benji York wrote:
...
Why does the display of the default DateTime widget change?
DatetimeWidget now use zope.i18n for parse and format values so the
display is the same as for DatetimeDisplayWidget (note the line
1529 of
the form.txt).
...and in such a strange way?
It's the datetime format for the default locale, see the
specification
in zope/i18n/locales/data/root.xml.
That breaks a test:
File
/home/tseaver/projects/Zope-CVS/tseaver-retire_zpkg-2.10/lib/
python/zope/formlib/form.txt,
line 1547, in form.txt
Failed example:
print MyAddForm(None, request)() # doctest: +NORMALIZE_WHITESPACE
Expected:
input class=textType id=form.identifier
name=form.identifier
size=10 type=text value= /
input class=textType id=form.name name=form.name size=20
type=text value= /
input class=textType id=form.min_size name=form.min_size
size=10 type=text value= /
input class=textType id=form.max_size name=form.max_size
size=10 type=text value= /
input class=textType id=form.now name=form.now size=20
type=text value=2002-12-02 12:30:00 /
Got:
input class=textType id=form.identifier
name=form.identifier
size=10 type=text value= /
input class=textType id=form.name name=form.name size=20
type=text value= /
input class=textType id=form.min_size name=form.min_size
size=10 type=text value= /
input class=textType id=form.max_size name=form.max_size
size=10 type=text value= /
input class=textType id=form.now name=form.now size=20
type=text value=2002 12 2 12:30:00 /
not onlyt that, but I don't believe that '2002 12 2 12:30:00' is a
valid date representation in *any* standard locale. The
dashes-with-leading-zeros should be the default (it is the stock ISO
date format).
Well, it's worse than that, for tests: if you are filling out forms
in a default locale (as you'll get without specifying one, or with
the test language), then you need to use the format shown in the test
above--and you *must* fill out the date with two spaces between the
date and time, seconds showing, *and* a subsequent space. For
instance, what you wrote ('2002 12 2 12:30:00') would not be parsed:
it needs to be '2002 12 2 12:30:00 ' (note last space).
As Stephan said in his reply, this is not anyone's fault in the Zope
community: it's what is specified in the ICU XML files in zope/i18n/
locales/data (specifically root.xml).
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.
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 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 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.
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 made zc.datetimewidget just default to the old behavior, because
the JS needs to have a workable definition of how to render dates,
and specifying ISO is nice and simple.)
Gary
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: SVN: Zope3/branches/3.3/ Fixed issue 525: DateWidget ru-format
Benji York wrote: Philipp von Weitershausen wrote: Dmitry Vasiliev wrote: Log message for revision 68818: Fixed issue 525: DateWidget ru-format - type=text value=2002-12-02 12:30:00 / + type=text value=2002 12 2 12:30:00 / Note that a EditForm can't make use of a get_rendered method. The get_rendered method does only set initial values. Why does the display of the default DateTime widget change? DatetimeWidget now use zope.i18n for parse and format values so the display is the same as for DatetimeDisplayWidget (note the line 1529 of the form.txt). ...and in such a strange way? It's the datetime format for the default locale, see the specification in zope/i18n/locales/data/root.xml. -- 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
[Zope3-dev] Re: SVN: Zope3/branches/3.3/ Fixed issue 525: DateWidget ru-format
Dmitry Vasiliev wrote: Log message for revision 68818: Fixed issue 525: DateWidget ru-format ... Modified: Zope3/branches/3.3/src/zope/formlib/form.txt === --- Zope3/branches/3.3/src/zope/formlib/form.txt 2006-06-24 09:00:09 UTC (rev 68817) +++ Zope3/branches/3.3/src/zope/formlib/form.txt 2006-06-24 09:02:44 UTC (rev 68818) @@ -1554,7 +1554,7 @@ input class=textType id=form.max_size name=form.max_size size=10 type=text value= / input class=textType id=form.now name=form.now size=20 - type=text value=2002-12-02 12:30:00 / + type=text value=2002 12 2 12:30:00 / Note that a EditForm can't make use of a get_rendered method. The get_rendered method does only set initial values. Why does the display of the default DateTime widget change? ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: SVN: Zope3/branches/3.3/ Fixed issue 525: DateWidget ru-format
Philipp von Weitershausen wrote: Dmitry Vasiliev wrote: Log message for revision 68818: Fixed issue 525: DateWidget ru-format - type=text value=2002-12-02 12:30:00 / + type=text value=2002 12 2 12:30:00 / Note that a EditForm can't make use of a get_rendered method. The get_rendered method does only set initial values. Why does the display of the default DateTime widget change? ...and in such a strange way? -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
