From: Brian S O'N. <bro...@ea...> - 2004-06-26 19:14:24
|
Cool! One thing that concerns me with AbstractPartialInstant is that it contains an array of fields, which I don't think is needed, except for a generic partial instant. For TimeOfDay, it can take on a bit more responsibility in mapping fields to indexes and indexes to fields. I'm trying out some changes. I'll create the rounded package, moving the old partial stuff in there. I'll chuck TimeOnly also. Printing and parsing of partials is really tricky since the formatters are designed to operate on fully resolved instants. Instants and their fields are weakly connected, but this is not true for partials. The formatter chooses the fields itself, but partials are very strict as to what fields it supports. Partials also support field values to be "de-normalized". Feb 31 is legal. Resolving a partial and then using an existing formatter will not work because of this. 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). > > >- TimeOnly disappears. >This class is not a fully specified instant in time, but a partial. Thus the >TimeOfDay class in the new partial package expresses it more clearly. > >- PartialInstant (main package) disappears >- ReadableInstant.getMillis disappears >See new PartialInstant and its resolve method. Some chronology methods for >date only and time only also disappear. > >- More partial work to do >! Formatting/Parsing >YearMonthDay >DayOfWeek (very useful for resolving to nearest day of week) >Longer term, a generic PartialDT that can have arbitrary fields set. > > >- More DateTimeField methods >setNext(value) >setPrevious(value) >(possibly one method using a multipler and negatives?) >eg. Wed, 2004-06-23 setNext(Thu) => Thu, 2004-06-24 >eg. Wed, 2004-06-23 setNext(Tue) => Tue, 2004-06-29 > > > >It took a while to work it all out, but it will be quite neat once done. >This is now my number one OSS priority, so I'm hoping to crack on now :-) > >Stephen > > >----- Original Message ----- >From: "Brian S O'Neill" <bro...@ea...> > > >>What is to become of the partial instant support in the main joda.time >>package? There are currently redundant classes/interfaces with the >>partial package. Does the TimeOnly class go away? Does DateOnly get >>replaced by something else? The getMillis methods that accept a base, do >>they go too? >> >>Right now things are in a bit of a mess, and I would like to know what >>the plan is, so that I can make changes. >> >> > > > > >------------------------------------------------------- >This SF.Net email sponsored by Black Hat Briefings & Training. >Attend Black Hat Briefings & Training, Las Vegas July 24-29 - >digital self defense, top technical experts, no vendor pitches, >unmatched networking opportunities. Visit www.blackhat.com >_______________________________________________ >Joda-interest mailing list >Jod...@li... >https://lists.sourceforge.net/lists/listinfo/joda-interest > > > |