Thanks very much for the detailed answer Greg.
Thanks Tommy for the links but the problem I have isn't related to
displaying of dates.
Specifically, I've narrowed it down to the type conversion carried out
by Struts.
The struts type conversion documentation states type conversion for
dates works as :
dates - uses the SHORT format for the Locale associated with the current
request
It seems that when my application is deployed on the US server, the
xwork validation/type conversion insists on the dates being US formatted
MM/dd/yyyy
despite my locale being reported by struts as:
<locale>
<ISO3Country>GBR</ISO3Country>
<ISO3Language>eng</ISO3Language>
<class>class java.util.Locale</class>
<country>GB</country>
<displayCountry>United Kingdom</displayCountry>
<displayLanguage>English</displayLanguage>
<displayName>English (United Kingdom)</displayName>
<displayVariant/>
<language>en</language>
<variant/>
</locale>
It seems that the Date conversion provided by struts/xwork is not
working in this case as expected.
I have no idea if this is a config issue or not.
If nobody else can shed a light on this problem, I shall fall back to
defining date fields as String and following the recommendations made by
Greg.
Greg Lindholm wrote:
Properly handling dates in a fully internationalized application can be
harder then you might think.
As in your example "Dec. 20, 2009" is not an absolute value, it depends on
which timezone the user is in because if may be Dec 20 in London, but it's
already Dec 21 in Hong Kong. And of course 12/10/2009 means different dates
depending on which country or region you are in.
So a date is only fully defined if you know both the TimeZone and the Locale
of the user.
In the apps I've written I always include the Locale and TimeZone as part of
the User object. Then I always use a DataFormat object and set both the
Locale and TimeZone, if you don't set them they will default to the servers
settings which often (but not always) are GMT ( which is almost always
incorrect for the user).
If you don't know the timezone or locale of the user (or have unregistered
users) then you could provide a select dropdown list that lets them specify
it as part of the request (then cookie it).
As a last and worst resort you could always tell them which timezone the app
is running in and what format you expect dates to be entered in.
In either case you do not want to use automatic String to Date conversion
for parameter setting. Have your 'date' field defined as a String and in
your action convert it to a Date using a DateFormat object based on the
TimeZone and Locale that you chose.
On a related note, if you are selecting records from a database based on a
Date field, (e.g. select orders for Dec 20, 2009) and your db column is a
datetime then you really need to specify your select as a range e.g. "select
orders where orderDate >= :startDate and orderDate < :endDate". To create
the startDate and endDate you use a Calender object and again you must set
the TimeZone and Locale (Calendar.getInstance(timeZone, locale);) you would
then set the date to the date you want (Dec 20, 2009) and set the time
portion to zero (Hours, minutes, seconds, milliseconds). For the the endDate
you would add one day to the calendar.
You range expression then gives you the 24 hour period that is considered
"Dec 20, 2009" for a user in that timezone.
Hope that helps.
On Wed, Sep 30, 2009 at 5:18 AM, Robin Mannering <ro...@mtndesigns.co.uk>wrote:
Hello,
Can anyone give me some 'best practice' advice for dealing with dates in
an international app (Struts2).
We are based in the UK and have an application running locally that
stores dates within action classes as java.util.Date.
These dates are sometimes passed to the application via querystring in
the format:
somePage.action?startDate=20/12/2009
The action class picks up this date and stores it correctly as the 20th
day of December when running locally.
However, on installation to our US based server (Struts 2 / Glassfish)
where of course date formats are mm/dd/yyyy, the action class makes the
assumption that we are trying to refer to the 20th month of the year and
so returns control to the input page with an accompanying error message.
I know this is to do with localization, but I am at a loss as to the
best practice for defining locales so that struts knows how to deal with
this kind of scenario.
The problem is passing those localized value back to the server action
classes.
Any advice would be gratefully received.
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.409 / Virus Database: 270.13.115/2404 - Release Date: 09/30/09 05:52:00
