Re: Handling user-specific timezones

[Igor Vaynberg]

On Thu, May 9, 2013 at 1:12 PM, Martin Grigorov  wrote:
> On Thu, May 9, 2013 at 9:45 PM, Igor Vaynberg wrote:
>
>> On Thu, May 9, 2013 at 12:32 PM, Martin Grigorov 
>> wrote:
>> > On Thu, May 9, 2013 at 5:37 PM, Igor Vaynberg > >wrote:
>> >
>> >> we should write components that work with multiple types.
>> >>
>> >
>> > But this will mean that we will have to re-write it to javax.time for the
>> > version of Wicket that will use JDK 8.
>> > Your suggestion doesn't sound attractive to me anymore :-/
>>
>> no, it just means we *add* handling for javax.time types when they
>> become available.
>>
>
> having support for both joda and javax.time sounds a bit too much
>
> additionally https://issues.apache.org/jira/browse/WICKET-466 is since
> 2007. Everyone knows the issues with j.u.Date/Calendar.
> The fact that JDK development is slow doesn't mean that we should be slow
> too. It is 6 years since this request has been made. Isn't it time to drop
> support for j.u.Date/Calendar ?

there are a lot of issues with j.u.Date. no one here is going to
dispute that. but, even with all these issues it is still a widely
used class, and will continue to be long after jdk8 is released.

i do not care if internally wicket used joda or anything else to
represent time. we can encapsulate whatever mechanism we want. but,
externally we should support j.u.Date as well as joda, etc.

for example, jpa codebases which need to be portable or jee apps can
only map j.u/s.Date and j.s.Timestamp because those are the only
temporal types jpa has support for. if we do not support these
directly then the users will either have to convert their domain to
perform conversion in getters/setters or use a model adapter to bind
to those types. either way, its a hassle, especially since its really
easy for us to support these types directly.

-igor



>
>
>>
>> >>
>> >> for example this is what code of a DateLabel might look like:
>> >>
>> >> @Override
>> >> public void onComponentTagBody(MarkupStream markupStream, ComponentTag
>> >> openTag) {
>> >>
>> >> String body = "";
>> >> Object date = getDefaultModelObject();
>> >> if (date != null) {
>> >>  if (date instanceof ReadablePartial) { body = ... }
>> >>  else if (date instanceof ReadableInstant) { body = ... }
>> >>  else if (date instanceof Date) { body = ...}
>> >>  else if (date instanceof Timestamp) { body = ... }
>> >>  else {
>> >> throw new IllegalStateException("Object of type :" +
>> >> date.getClass().getName() + " is not supported");
>> >>   }
>> >> }
>> >> replaceComponentTagBody(markupStream, openTag, body);
>> >> }
>> >>
>> >> we are not using a converter because DateLabel carries a format string
>> >> as a property.
>> >>
>> >> such a component is convenient because you dont need to worry if you
>> >> are using it with older api that has Date or a newer one that has Joda
>> >>
>> >> we cannot go solely on threeten because version 1.0 is not coming
>> >> until jdk8 and only with jdk8.
>> >>
>> >
>> > I don't get the "only with jdk8" part.
>> >
>> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.threeten%22%20AND%20a%3A%22threetenbp%22
>> > threetenbp is the backport for JDK 7. It is version 0.8.1 at the moment
>> so
>> > API changes may be expected, but it can be used now.
>>
>> right. but can we have a production version with a pre 1.0 dependency?
>> as far as semver goes pre 1.0 is the wild west - anything can change.
>> i think thats a bit dicy. and even if we do that, we should still
>> suport java.util.Date and java.sql.Timestamp. these types are in wide
>> use currently and will be for a while.
>>
>> -igor
>>
>>
>> >
>> >
>> >>
>> >> -igor
>> >>
>> >> On Thu, May 9, 2013 at 12:03 AM, Martin Grigorov 
>> >> wrote:
>> >> > Hi Dan,
>> >> >
>> >> > I have no much experience with this matter so I cannot help much.
>> >> >
>> >> > The new Joda-Time is http://threeten.github.io/
>> >> >
>> >> > Question to other devs: do you think it is OK to migrate
>> wicket-datetime
>> >> > module to JDK 1.7 version of ThreeTen for Wicket 7 ?
>> >> > I find this task interesting to me so I'll gladly work on it if other
>> >> devs
>> >> > think that the API break is worth it.
>> >> >
>> >> >
>> >> >
>> >> > On Thu, May 9, 2013 at 12:46 AM, 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)?
>> >> >>
>> >> >> Do you avoid MessageFormats in StringResourceModels? (I don't see a
>> way
>> >> to
>> >> >> configure its MessageFormat.)
>> >> >>
>> >> >> 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
>> applica

Re: Handling user-specific timezones

[Martin Grigorov]

On Thu, May 9, 2013 at 9:45 PM, Igor Vaynberg wrote:

> On Thu, May 9, 2013 at 12:32 PM, Martin Grigorov 
> wrote:
> > On Thu, May 9, 2013 at 5:37 PM, Igor Vaynberg  >wrote:
> >
> >> we should write components that work with multiple types.
> >>
> >
> > But this will mean that we will have to re-write it to javax.time for the
> > version of Wicket that will use JDK 8.
> > Your suggestion doesn't sound attractive to me anymore :-/
>
> no, it just means we *add* handling for javax.time types when they
> become available.
>

having support for both joda and javax.time sounds a bit too much

additionally https://issues.apache.org/jira/browse/WICKET-466 is since
2007. Everyone knows the issues with j.u.Date/Calendar.
The fact that JDK development is slow doesn't mean that we should be slow
too. It is 6 years since this request has been made. Isn't it time to drop
support for j.u.Date/Calendar ?


>
> >>
> >> for example this is what code of a DateLabel might look like:
> >>
> >> @Override
> >> public void onComponentTagBody(MarkupStream markupStream, ComponentTag
> >> openTag) {
> >>
> >> String body = "";
> >> Object date = getDefaultModelObject();
> >> if (date != null) {
> >>  if (date instanceof ReadablePartial) { body = ... }
> >>  else if (date instanceof ReadableInstant) { body = ... }
> >>  else if (date instanceof Date) { body = ...}
> >>  else if (date instanceof Timestamp) { body = ... }
> >>  else {
> >> throw new IllegalStateException("Object of type :" +
> >> date.getClass().getName() + " is not supported");
> >>   }
> >> }
> >> replaceComponentTagBody(markupStream, openTag, body);
> >> }
> >>
> >> we are not using a converter because DateLabel carries a format string
> >> as a property.
> >>
> >> such a component is convenient because you dont need to worry if you
> >> are using it with older api that has Date or a newer one that has Joda
> >>
> >> we cannot go solely on threeten because version 1.0 is not coming
> >> until jdk8 and only with jdk8.
> >>
> >
> > I don't get the "only with jdk8" part.
> >
> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.threeten%22%20AND%20a%3A%22threetenbp%22
> > threetenbp is the backport for JDK 7. It is version 0.8.1 at the moment
> so
> > API changes may be expected, but it can be used now.
>
> right. but can we have a production version with a pre 1.0 dependency?
> as far as semver goes pre 1.0 is the wild west - anything can change.
> i think thats a bit dicy. and even if we do that, we should still
> suport java.util.Date and java.sql.Timestamp. these types are in wide
> use currently and will be for a while.
>
> -igor
>
>
> >
> >
> >>
> >> -igor
> >>
> >> On Thu, May 9, 2013 at 12:03 AM, Martin Grigorov 
> >> wrote:
> >> > Hi Dan,
> >> >
> >> > I have no much experience with this matter so I cannot help much.
> >> >
> >> > The new Joda-Time is http://threeten.github.io/
> >> >
> >> > Question to other devs: do you think it is OK to migrate
> wicket-datetime
> >> > module to JDK 1.7 version of ThreeTen for Wicket 7 ?
> >> > I find this task interesting to me so I'll gladly work on it if other
> >> devs
> >> > think that the API break is worth it.
> >> >
> >> >
> >> >
> >> > On Thu, May 9, 2013 at 12:46 AM, 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)?
> >> >>
> >> >> Do you avoid MessageFormats in StringResourceModels? (I don't see a
> way
> >> to
> >> >> configure its MessageFormat.)
> >> >>
> >> >> 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.
> >> >>
> >> >> Thanks,
> >> >> Dan
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Martin Grigorov
> >> > Wicket Training & Consulting
> >> > http://jWeekend.com 
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> For 

Re: Handling user-specific timezones

[Bertrand Guay-Paquet]

On 09/05/2013 3:30 PM, Dan Retzlaff wrote:

Thanks, Bertrand.

On Thu, May 9, 2013 at 9:47 AM, Bertrand Guay-Paquet 
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: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Handling user-specific timezones

[Igor Vaynberg]

On Thu, May 9, 2013 at 12:32 PM, Martin Grigorov  wrote:
> On Thu, May 9, 2013 at 5:37 PM, Igor Vaynberg wrote:
>
>> we should write components that work with multiple types.
>>
>
> But this will mean that we will have to re-write it to javax.time for the
> version of Wicket that will use JDK 8.
> Your suggestion doesn't sound attractive to me anymore :-/

no, it just means we *add* handling for javax.time types when they
become available.

>>
>> for example this is what code of a DateLabel might look like:
>>
>> @Override
>> public void onComponentTagBody(MarkupStream markupStream, ComponentTag
>> openTag) {
>>
>> String body = "";
>> Object date = getDefaultModelObject();
>> if (date != null) {
>>  if (date instanceof ReadablePartial) { body = ... }
>>  else if (date instanceof ReadableInstant) { body = ... }
>>  else if (date instanceof Date) { body = ...}
>>  else if (date instanceof Timestamp) { body = ... }
>>  else {
>> throw new IllegalStateException("Object of type :" +
>> date.getClass().getName() + " is not supported");
>>   }
>> }
>> replaceComponentTagBody(markupStream, openTag, body);
>> }
>>
>> we are not using a converter because DateLabel carries a format string
>> as a property.
>>
>> such a component is convenient because you dont need to worry if you
>> are using it with older api that has Date or a newer one that has Joda
>>
>> we cannot go solely on threeten because version 1.0 is not coming
>> until jdk8 and only with jdk8.
>>
>
> I don't get the "only with jdk8" part.
> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.threeten%22%20AND%20a%3A%22threetenbp%22
> threetenbp is the backport for JDK 7. It is version 0.8.1 at the moment so
> API changes may be expected, but it can be used now.

right. but can we have a production version with a pre 1.0 dependency?
as far as semver goes pre 1.0 is the wild west - anything can change.
i think thats a bit dicy. and even if we do that, we should still
suport java.util.Date and java.sql.Timestamp. these types are in wide
use currently and will be for a while.

-igor


>
>
>>
>> -igor
>>
>> On Thu, May 9, 2013 at 12:03 AM, Martin Grigorov 
>> wrote:
>> > Hi Dan,
>> >
>> > I have no much experience with this matter so I cannot help much.
>> >
>> > The new Joda-Time is http://threeten.github.io/
>> >
>> > Question to other devs: do you think it is OK to migrate wicket-datetime
>> > module to JDK 1.7 version of ThreeTen for Wicket 7 ?
>> > I find this task interesting to me so I'll gladly work on it if other
>> devs
>> > think that the API break is worth it.
>> >
>> >
>> >
>> > On Thu, May 9, 2013 at 12:46 AM, 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)?
>> >>
>> >> Do you avoid MessageFormats in StringResourceModels? (I don't see a way
>> to
>> >> configure its MessageFormat.)
>> >>
>> >> 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.
>> >>
>> >> Thanks,
>> >> Dan
>> >>
>> >
>> >
>> >
>> > --
>> > Martin Grigorov
>> > Wicket Training & Consulting
>> > http://jWeekend.com 
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
>
> --
> Martin Grigorov
> Wicket Training & Consulting
> http://jWeekend.com 

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Handling user-specific timezones

[Martin Grigorov]

On Thu, May 9, 2013 at 5:37 PM, Igor Vaynberg wrote:

> we should write components that work with multiple types.
>

But this will mean that we will have to re-write it to javax.time for the
version of Wicket that will use JDK 8.
Your suggestion doesn't sound attractive to me anymore :-/


>
> for example this is what code of a DateLabel might look like:
>
> @Override
> public void onComponentTagBody(MarkupStream markupStream, ComponentTag
> openTag) {
>
> String body = "";
> Object date = getDefaultModelObject();
> if (date != null) {
>  if (date instanceof ReadablePartial) { body = ... }
>  else if (date instanceof ReadableInstant) { body = ... }
>  else if (date instanceof Date) { body = ...}
>  else if (date instanceof Timestamp) { body = ... }
>  else {
> throw new IllegalStateException("Object of type :" +
> date.getClass().getName() + " is not supported");
>   }
> }
> replaceComponentTagBody(markupStream, openTag, body);
> }
>
> we are not using a converter because DateLabel carries a format string
> as a property.
>
> such a component is convenient because you dont need to worry if you
> are using it with older api that has Date or a newer one that has Joda
>
> we cannot go solely on threeten because version 1.0 is not coming
> until jdk8 and only with jdk8.
>

I don't get the "only with jdk8" part.
http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.threeten%22%20AND%20a%3A%22threetenbp%22
threetenbp is the backport for JDK 7. It is version 0.8.1 at the moment so
API changes may be expected, but it can be used now.


>
> -igor
>
> On Thu, May 9, 2013 at 12:03 AM, Martin Grigorov 
> wrote:
> > Hi Dan,
> >
> > I have no much experience with this matter so I cannot help much.
> >
> > The new Joda-Time is http://threeten.github.io/
> >
> > Question to other devs: do you think it is OK to migrate wicket-datetime
> > module to JDK 1.7 version of ThreeTen for Wicket 7 ?
> > I find this task interesting to me so I'll gladly work on it if other
> devs
> > think that the API break is worth it.
> >
> >
> >
> > On Thu, May 9, 2013 at 12:46 AM, 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)?
> >>
> >> Do you avoid MessageFormats in StringResourceModels? (I don't see a way
> to
> >> configure its MessageFormat.)
> >>
> >> 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.
> >>
> >> Thanks,
> >> Dan
> >>
> >
> >
> >
> > --
> > Martin Grigorov
> > Wicket Training & Consulting
> > http://jWeekend.com 
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


-- 
Martin Grigorov
Wicket Training & Consulting
http://jWeekend.com 

Re: Handling user-specific timezones

[Dan Retzlaff]

Thanks, Bertrand.

On Thu, May 9, 2013 at 9:47 AM, Bertrand Guay-Paquet  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

Re: Handling user-specific timezones

[Bertrand Guay-Paquet]

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: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Handling user-specific timezones

[Igor Vaynberg]

we should write components that work with multiple types.

for example this is what code of a DateLabel might look like:

@Override
public void onComponentTagBody(MarkupStream markupStream, ComponentTag
openTag) {

String body = "";
Object date = getDefaultModelObject();
if (date != null) {
 if (date instanceof ReadablePartial) { body = ... }
 else if (date instanceof ReadableInstant) { body = ... }
 else if (date instanceof Date) { body = ...}
 else if (date instanceof Timestamp) { body = ... }
 else {
throw new IllegalStateException("Object of type :" +
date.getClass().getName() + " is not supported");
  }
}
replaceComponentTagBody(markupStream, openTag, body);
}

we are not using a converter because DateLabel carries a format string
as a property.

such a component is convenient because you dont need to worry if you
are using it with older api that has Date or a newer one that has Joda

we cannot go solely on threeten because version 1.0 is not coming
until jdk8 and only with jdk8.

-igor

On Thu, May 9, 2013 at 12:03 AM, Martin Grigorov  wrote:
> Hi Dan,
>
> I have no much experience with this matter so I cannot help much.
>
> The new Joda-Time is http://threeten.github.io/
>
> Question to other devs: do you think it is OK to migrate wicket-datetime
> module to JDK 1.7 version of ThreeTen for Wicket 7 ?
> I find this task interesting to me so I'll gladly work on it if other devs
> think that the API break is worth it.
>
>
>
> On Thu, May 9, 2013 at 12:46 AM, 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)?
>>
>> Do you avoid MessageFormats in StringResourceModels? (I don't see a way to
>> configure its MessageFormat.)
>>
>> 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.
>>
>> Thanks,
>> Dan
>>
>
>
>
> --
> Martin Grigorov
> Wicket Training & Consulting
> http://jWeekend.com 

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Handling user-specific timezones

[Martin Grigorov]

Hi Dan,

I have no much experience with this matter so I cannot help much.

The new Joda-Time is http://threeten.github.io/

Question to other devs: do you think it is OK to migrate wicket-datetime
module to JDK 1.7 version of ThreeTen for Wicket 7 ?
I find this task interesting to me so I'll gladly work on it if other devs
think that the API break is worth it.



On Thu, May 9, 2013 at 12:46 AM, 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)?
>
> Do you avoid MessageFormats in StringResourceModels? (I don't see a way to
> configure its MessageFormat.)
>
> 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.
>
> Thanks,
> Dan
>



-- 
Martin Grigorov
Wicket Training & Consulting
http://jWeekend.com 

Handling user-specific timezones

[Dan Retzlaff]

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)?

Do you avoid MessageFormats in StringResourceModels? (I don't see a way to
configure its MessageFormat.)

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.

Thanks,
Dan