From: Stephen C. <sco...@jo...> - 2004-06-26 23:42:24
|
Sounds interesting! I think that we will still want some concrete (immutable) implementations of the rounding though? It doesn't feel quite right creating a 'DateTime' and then only using the date parts. I maybe wrong though, can't tell until I see how the API works out from this idea. Can probably wait until after you check in the basic support for final decisions on this. BTW, Partial YearMonthDay now checked in. DayOfWeek is just seven constants, so it needs to be coded differently ;-) Stephen ----- Original Message ----- From: "Brian S O'Neill" <bro...@ea...> > I've been working on a rounded package for a bit now, but I think it is > more work than needed. I think all I really need to do is support > rounding in AbstractDateTime. Protected methods define the rounding mode > and field. When setMillis is called, rounding is applied. > MutableDateTime allows the rounding options to be changed, and DateTime > has "with" methods to create new instances that round differently. > > In short, this means that all the old classes go, and no new ones are > needed to replace them. > > Stephen Colebourne wrote: > > >OK, here is the plan as I see it..... > > > >- RoundedDateTime > >A ReadableInstant with a specific rounding point below which everything is > >forced to zero. A rounded subpackage may be useful here. > > > >- DateOnly becomes DateMidnight > >This is a fully specified instant in time (so it implements > >ReadableInstant), but it just forces time to midnight. (And is a special > >version of RoundedDateTime). DateHMS might also be a useful implementation, > >as might DateHM (my current job is in travel and seconds and milliseconds > >are not relevant there). > > > > > > |