Hi!
On 08/05/2013 6:46 PM, Dan Retzlaff wrote:
Hi all,
I'd like to know what conventions you've established for your sites that
deal with users in many time zones.
Do you simply replace the converters (Date, SqlDate, SqlTime, SqlTimestamp)?
I make sure that all the date objects sent to Wicket are of type
java.util.date (in direct violation of your point #3 below!) and I
replaced the default Wicket Date converter because I don't like some of
the formatting choices made for some locales.
Do you avoid MessageFormats in StringResourceModels? (I don't see a way to
configure its MessageFormat.)
I convert my Dates to strings with the proper converter before passing
them on to string resources.
We currently bypass this stuff and do our formatting with application
utility methods, and adapting input into users' timezones as manual steps,
e.g. with Joda-Time's DateTime#withZoneRetainFields().
I'd like to sweep this stuff under the rug with some application-level
configuration, e.g. of converters. But before I embark, I was hoping to
hear from someone who's already gone on this journey.
And related: maybe you have some golden rules time zone handling to share?
A couple of mine are:
1. Avoid "date" types in SQL tables because it's hard to correctly compare
to "now" across timezones.
2. Anything that shifts millis to adjust for timezones is a red flag
(including the aforementioned #withZoneRetainFields() sadly).
3. java.util.Date is evil and you should avoid it whenever possible.
Calendar is marginally better, but Joda-Time is the way to go.
Using converters with applyTimeZoneDifference=true works fine for me
once the timezone is set in the Session.
I follow these rules to avoid all the fuss:
1-The application's JVM and joda-time default time zones are UTC
(-Duser.timezone=UTC). Throw an exception in application init if that's
not the case.
2-MySQL is set to the UTC timezone (default-time-zone=UTC)
3-MySQL jdbc connector: set useLegacyDatetimeCode=false
4-Never store timezone information in database date fields
5-ALWAYS use UTC times EXCEPT when converting to user's time zone for
display or converting to UTC when handling input. These last 2 actions
are handled correctly when using converters with
applyTimeZoneDifference=true.
#5 really implies all the other rules. Considering that my server (or my
unit tests) could be moved anywhere in any timezone, it makes no sense
to use any other timezone than UTC internally to me.
Some references I noted when doing research on this:
http://stackoverflow.com/questions/309203/how-to-store-a-java-util-date-into-a-mysql-timestamp-field-in-the-utc-gmt-timezon
http://dev.mysql.com/doc/refman/5.1/en/connector-j-reference-configuration-properties.html
http://www.odi.ch/prog/design/datetime.php
http://bugs.mysql.com/bug.php?id=15604
http://stackoverflow.com/questions/508019/jpa-hibernate-store-date-in-utc-time-zone
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
