wicket-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Grigorov <mgrigo...@apache.org>
Subject Re: Handling user-specific timezones
Date Thu, 09 May 2013 20:12:38 GMT
On Thu, May 9, 2013 at 9:45 PM, Igor Vaynberg <igor.vaynberg@gmail.com>wrote:

> On Thu, May 9, 2013 at 12:32 PM, Martin Grigorov <mgrigorov@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 <mgrigorov@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 <dretzlaff@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/>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message