On Thu, May 9, 2013 at 9:45 PM, Igor Vaynberg <igor.vaynb...@gmail.com>wrote:
> On Thu, May 9, 2013 at 12:32 PM, Martin Grigorov <mgrigo...@apache.org> > wrote: > > On Thu, May 9, 2013 at 5:37 PM, Igor Vaynberg <igor.vaynb...@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 <mgrigo...@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 <dretzl...@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-unsubscr...@wicket.apache.org > >> For additional commands, e-mail: users-h...@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/>
