Yes, I do think it makes sense. I just can't quite get my head around what
the right API would be for the add and addWrapped methods.
The four properties you give below make perfect sense, as does the
unit/wholeUnit thing. But the add?
dt.dayOfMonth().unit().add(6);
dt.day().add(6);
dt.add(DateTimeUnit.DAY, 6);
dt.addDays(6);
We already have the last one, so I guess that could hide any of the others.
Any more ideas?
The JADE framework has the concept of Durations, but it is targetted at a
more scientific market. If we can, I'd like to keep Joda time dependency
free.
Stephen
----- Original Message -----
From: "Brian O'Neill" <Brian.ONeill@...>
> A DateTimeUnit class would solve some problems I have in establishing
> DateTimeFormatterBuilder parsing priorities. I think the DateTimeFields
can
> reference a (publicly available) DateTimeUnit, and DateTimeField.add can
> delegate to that.
>
> Some properties fo DateTimeUnit that I can think of:
>
> - minimumSizeMillis (355 days in cutover year)
> - maximumSizeMillis (366 days per leap year)
> - typicalSizeMillis (365 days per typical year)
> - averageSizeMillis (365.2425 days per gregorian year)
>
> Fields like dayOfYear could actually reference two units, one for day, and
> one for year. I don't know what the two would be called, however. Unit vs
> whole unit?
>
> Could date units fit into the JADE framework?
>
> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@...]
> Sent: Thursday, November 21, 2002 12:46 PM
> To: Joda Interest
> Subject: Re: [Joda-interest] TimePeriod design
>
>
> I think that they are pretty much open to suggestions. The current design
> tries to follow that of the ISO standard, which is fine, but too limiting
> for what we have now.
>
> I had thought that one solution was a DateTimeUnit class similar to
> DateTimeField. This would be technically more correct, as
> dt.dayOfMonth().add()
> dt.dayOfWeek().add()
> dt.dayOfYear().add()
> all do the same thing, because you can't really add a 'day of week', but
you
> can add a 'day'.
>
> However, this would be quite a bit of rearchitecturing, and I worry that
it
> might be more accurate, but a more complex API for dates. Time periods
would
> be easier however as they would become a group of DateTimeUnits.
>
> Stephen
>
>
> ----- Original Message -----
> From: "Brian O'Neill" <Brian.ONeill@...>
> To: "Joda Interest" <joda-interest@...>
> Sent: Wednesday, November 20, 2002 11:32 PM
> Subject: [Joda-interest] TimePeriod design
>
>
> > As per TODO.txt: "TimePeriods: Review in light of DateTimeFields".
> >
> > What is the desired evolution of these classes?
> >
> > One feature that I see lacking is support for more intuitive time
> > periods, where the days per month isn't fixed at 30. I'd like to be
> > able to pass in
> a
> > birthday, today, and a chronology. With this I can get age in years,
> months,
> > days, or age in months, etc. With a fixed month length, this doesn't
> produce
> > accurate results.
> >
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf _______________________________________________
> Joda-interest mailing list
> Joda-interest@...
> https://lists.sourceforge.net/lists/listinfo/joda-interest
>
|