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.
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.
> 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.
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.
We use TIMESTAMP for auto-updated fields (created, updated), and DATETIME
elsewhere. I think our system would be simpler if we used TIMESTAMP
consistently. TIMESTAMP's use of millis reduces impedance mismatch with
Java types, and the automatic conversion into DB session's timezone makes
business analytics easy to run in any timezone without lots of CONVERT_TZ.
Plus TIMESTAMP is 4 bytes vs DATETIME's 8 bytes. We have only a couple of
use cases that actually need "wall clock time."
(I know this discussion deviates from Wicket, but I'm trying to develop a
holistic view.)
Dan
