You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Martin Grigorov <mg...@apache.org> on 2013/05/09 09:03:51 UTC
Re: Handling user-specific timezones
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 <dr...@gmail.com> 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 <http://jweekend.com/>
Re: Handling user-specific timezones
Posted by Igor Vaynberg <ig...@gmail.com>.
On Thu, May 9, 2013 at 1:12 PM, Martin Grigorov <mg...@apache.org> wrote:
> On Thu, May 9, 2013 at 9:45 PM, Igor Vaynberg <ig...@gmail.com>wrote:
>
>> On Thu, May 9, 2013 at 12:32 PM, Martin Grigorov <mg...@apache.org>
>> wrote:
>> > On Thu, May 9, 2013 at 5:37 PM, Igor Vaynberg <igor.vaynberg@gmail.com
>> >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 <mg...@apache.org>
>> >> 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 <dr...@gmail.com>
>> >> 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 <http://jweekend.com/>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > Martin Grigorov
>> > Wicket Training & Consulting
>> > http://jWeekend.com <http://jweekend.com/>
>>
>
>
>
> --
> Martin Grigorov
> Wicket Training & Consulting
> http://jWeekend.com <http://jweekend.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Handling user-specific timezones
Posted by Igor Vaynberg <ig...@gmail.com>.
On Thu, May 9, 2013 at 1:12 PM, Martin Grigorov <mg...@apache.org> wrote:
> On Thu, May 9, 2013 at 9:45 PM, Igor Vaynberg <ig...@gmail.com>wrote:
>
>> On Thu, May 9, 2013 at 12:32 PM, Martin Grigorov <mg...@apache.org>
>> wrote:
>> > On Thu, May 9, 2013 at 5:37 PM, Igor Vaynberg <igor.vaynberg@gmail.com
>> >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 <mg...@apache.org>
>> >> 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 <dr...@gmail.com>
>> >> 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 <http://jweekend.com/>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > Martin Grigorov
>> > Wicket Training & Consulting
>> > http://jWeekend.com <http://jweekend.com/>
>>
>
>
>
> --
> Martin Grigorov
> Wicket Training & Consulting
> http://jWeekend.com <http://jweekend.com/>
Re: Handling user-specific timezones
Posted by Martin Grigorov <mg...@apache.org>.
On Thu, May 9, 2013 at 9:45 PM, Igor Vaynberg <ig...@gmail.com>wrote:
> On Thu, May 9, 2013 at 12:32 PM, Martin Grigorov <mg...@apache.org>
> wrote:
> > On Thu, May 9, 2013 at 5:37 PM, Igor Vaynberg <igor.vaynberg@gmail.com
> >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 <mg...@apache.org>
> >> 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 <dr...@gmail.com>
> >> 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 <http://jweekend.com/>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
> > --
> > Martin Grigorov
> > Wicket Training & Consulting
> > http://jWeekend.com <http://jweekend.com/>
>
--
Martin Grigorov
Wicket Training & Consulting
http://jWeekend.com <http://jweekend.com/>
Re: Handling user-specific timezones
Posted by Martin Grigorov <mg...@apache.org>.
On Thu, May 9, 2013 at 9:45 PM, Igor Vaynberg <ig...@gmail.com>wrote:
> On Thu, May 9, 2013 at 12:32 PM, Martin Grigorov <mg...@apache.org>
> wrote:
> > On Thu, May 9, 2013 at 5:37 PM, Igor Vaynberg <igor.vaynberg@gmail.com
> >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 <mg...@apache.org>
> >> 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 <dr...@gmail.com>
> >> 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 <http://jweekend.com/>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
> > --
> > Martin Grigorov
> > Wicket Training & Consulting
> > http://jWeekend.com <http://jweekend.com/>
>
--
Martin Grigorov
Wicket Training & Consulting
http://jWeekend.com <http://jweekend.com/>
Re: Handling user-specific timezones
Posted by Igor Vaynberg <ig...@gmail.com>.
On Thu, May 9, 2013 at 12:32 PM, Martin Grigorov <mg...@apache.org> wrote:
> On Thu, May 9, 2013 at 5:37 PM, Igor Vaynberg <ig...@gmail.com>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 <mg...@apache.org>
>> 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 <dr...@gmail.com>
>> 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 <http://jweekend.com/>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> --
> Martin Grigorov
> Wicket Training & Consulting
> http://jWeekend.com <http://jweekend.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Handling user-specific timezones
Posted by Igor Vaynberg <ig...@gmail.com>.
On Thu, May 9, 2013 at 12:32 PM, Martin Grigorov <mg...@apache.org> wrote:
> On Thu, May 9, 2013 at 5:37 PM, Igor Vaynberg <ig...@gmail.com>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 <mg...@apache.org>
>> 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 <dr...@gmail.com>
>> 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 <http://jweekend.com/>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> --
> Martin Grigorov
> Wicket Training & Consulting
> http://jWeekend.com <http://jweekend.com/>
Re: Handling user-specific timezones
Posted by Martin Grigorov <mg...@apache.org>.
On Thu, May 9, 2013 at 5:37 PM, Igor Vaynberg <ig...@gmail.com>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 <mg...@apache.org>
> 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 <dr...@gmail.com>
> 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 <http://jweekend.com/>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Martin Grigorov
Wicket Training & Consulting
http://jWeekend.com <http://jweekend.com/>
Re: Handling user-specific timezones
Posted by Martin Grigorov <mg...@apache.org>.
On Thu, May 9, 2013 at 5:37 PM, Igor Vaynberg <ig...@gmail.com>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 <mg...@apache.org>
> 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 <dr...@gmail.com>
> 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 <http://jweekend.com/>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Martin Grigorov
Wicket Training & Consulting
http://jWeekend.com <http://jweekend.com/>
Re: Handling user-specific timezones
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <mg...@apache.org> 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 <dr...@gmail.com> 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 <http://jweekend.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Handling user-specific timezones
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <mg...@apache.org> 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 <dr...@gmail.com> 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 <http://jweekend.com/>