On 09/05/2013 3:30 PM, Dan Retzlaff wrote:
Thanks, Bertrand.
On Thu, May 9, 2013 at 9:47 AM, Bertrand Guay-Paquet <[email protected]
wrote:
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.
If StringResourceModel accounted for the session's timezone (like
wicket-datetime's DateConverter), would you consider using
MessageFormat-based resources? Or is there another advantage to converting
to String in application code? This is an example of what I'd like to make
sensitive to user timezone, but don't see how.
In my case, since I override some of joda-time's date format strings in
some locales, it would need to provide a way to customize the format
strings per-locale. If you're fine with the default format strings, I
guess it would work.
localtime=Your local time is {0,time,medium}
add(new Label("localtime", new StringResourceModel("localtime", null, new
Date())));
Instead I have essentially:
localtime=Your local time is {0}
add(new Label("localtime", new StringResourceModel("localtime", null,
MySession.formatTime(new Date(), DateFormat.MEDIUM))));
Using converters with applyTimeZoneDifference=true works fine for me once
the timezone is set in the Session.
Holy smokes, I didn't realize wicket-datetime wasn't on my classpath! The
Joda-based classes there definitely obviate a couple of my classes.
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)
That's hardcore to require that in dev environments. We've been allowing
system time in dev, and UTC in CI builds, stage and prod. I'll think about
moving dev over. I can't say we haven't had bugs because of the
inconsistency.
It might be hardcore, but at least it has an early fail so it's easy to
catch.
For deploying the app in dev, I simply configured the servlet
container's JVM to use UTC. This might not be an option if you have many
servlets running I guess. In that case, the app init could set the
default timezone programatically.
For the unit tests, my base wicket tester classes takes care of settings
the server timezone.
3-MySQL jdbc connector: set useLegacyDatetimeCode=false
This protects against issues with Calendars in your JPA entities / JDBC
statements, right? We use j.u.Date pretty consistently in entities so I
think this is not relevant to us. That's a good bug to know about, and it's
too bad they can't simply default to the improved behavior.
I re-read some doc about this option and the bug report I linked to and
it seems that I don't really need this if the client's JVM is using UTC
and the DB is using UTC too. It's just there in case I access the
database with a client who's JVM timezone is not UTC.
4-Never store timezone information in database date fields
AFAIK, neither DATETIME nor TIMESTAMP actually stores the timezone, so
I'm not sure what you're warning against specifically.
MySQL doesn't support it, but other vendors have the "TIMESTAMP WITH
TIME ZONE" data type.
Regards,
Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
