David E Jones wrote:
Adrian Crum wrote:
5. Modify the form widget to support user selected time zones and
locales. Currently the form widget forces the user to input date/time
in the server's format and time zone. I haven't started on that yet.
I'm not totally sure what you have in mind here, but I'll keep an eye
out for more info from you and see if I can help out.
IMO the main priority for this is to properly support time zones. I'm
still a big fan of the descending date/time format instead of using
localized formats. The problem with those is that there are either too
few or too many "standards" and so unless you show a format string with
every input box it can be VERY confusing and frustrating to figure out
how to type in a date and/or time. We also need to keep in the mind that
the popup window for date selection would need to have something passed
into it so it knows how to format the date/time string based on the
selection.
So yeah, in general I'm a big fan of using the descending format
everywhere, even consumer/public facing applications (at least as a
default, there are certainly tools to support other formats as needed
for custom UIs).
-David
David,
There are two date/time issues that need to be addressed in the form widget:
1. Converting Strings to/from Timestamps using the user's time zone. I'm thinking this is something
that needs to be controlled by a widget XML element attribute - since there may be cases where the
server's time zone should be used. It would be best to have the widget default to the server's time
zone (for backward compatibility) and have time zone support switched on through an XML element
attribute.
2. Date/time input format. I agree that the descending format should be retained for consistency
sake. However, our users prefer to input dates in the mm/dd/yyyy format. So, I'll leave that issue
alone and let someone else tackle the configurable data entry format that Daniel Martinez proposed.
-Adrian
