From: xiaomei j. <xia...@gm...> - 2008-02-02 06:43:57
|
Hi Yoshito, George, You raised the following 2 issues on the design proposal I send out earlier: 1. issues as to DateIntervalFormat::createInstance(DateFormat*, const Locale&, UErrorCode& ) 1.1 why use DateFormat instead of SimpleDateFormat. 1.2 why construct it using full pattern vs. skeleton. 2. issues as to the interval pattern representation I proposed "d MMM - d MMM yyyy". Yoshito raised question that it does not support interval pattern in which the later date comes first in the pattern. Mark, Doug, Markus, and I discussed above 2 issues and come up with the following proposals: 1. DateIntervalFormat factory method. We will use skeleton-based factory. 1.1 we will introduce a set ( ~30 ) of predefined macros for predefined skeletons supported in resource files. For example #define DAY_MONTH_YEAR_DOW_FULL_FORMAT "EEEEdMMMMy" #define DAY_MONTH_FULL_FORMAT "dMMMM". We could use skeleton string or skeleton enum. The rationale to define a set of skeleton strings are: Either way ( enum or string ), we need to keep consistency between DateFormat and DateIntervalFormat factory methods. We feel it is not good to introduce another set of enum for skeleton while having EStyle for full pattern. And it is not good to mix the set of enum for skeleton into EStyle. But we do think it is better to have skeletons predefined. So, we came up with a set of skeleton strings ( not enum ), but predefined as macros. 1.2 Factory methods using DateFormat as input will be removed. And following factory method will be introduced: createInstance(UnicodeString& skeleton, UBool adjustWidth, const Locale& locale, UErrorCode& status) In which, adjustWidth means whether we want to adjust the skeleton field width or not. It is used for DateTimePatternGenerator on whether to adjust field width when get full pattern from skeleton. The caller can construct DateIntervalFormat using predefined macro, for example: DateIntervalFormat::createInstance(UnicodeString(DAY_MONTH_FULL_FORMAT), FALSE, loc, status) 1.3 a factory method using skeleton is introduced for DateFormat as well to keep it consistent with DateIntervalFormat. DateFormat::createInstance(UnicodeString& skeleton, UBool adjustWidth, const Locale& locale) 1.4 a boolean parameter will be introduced in DateTimePatternGenerator::getPatternFromSkeleton() to controll whether adjust the skeleton field width or not. 2. As to the inteval format representation. For those interval patterns where first date comes in the pattern earlier, the interval patterns are kept as what proposed last time. For example "d MMM - d MMM yyyy". For those intervan patterns where later date comes in the pattern earlier, the interval patterns are prefixed with "later_first:". For example: "later_first:d MMM - d MMM yyyy". Underlying, a boolean will be introduced as to whether it is earlier date first or later date first. And the interval pattern is splitted into 2 date format part: pattern from earlier date and pattern from later date. The rational behind this proposal are: 2.1 we can use the existing parsing code by using the standard strings 2.2 above proposal is more intuitive and easy for users to undertand The assumption we are making is fields from earlier date and later date are not mixed. For example, there is no case that "{1, EEEE,} {0, d} { 1, MMM } - {0, EEEE} {1, d} {0, MMM} {1, yyyy}" holds true. Thanks, Xiaomei On 2/1/08, yos...@us... <yos...@us...> wrote: > > A pattern is tied with a set of symbols and exact algorithm. A skelton > hides the order of fields, but still depends on individual field's pattern > length. When you develop an internationalized software, you basically > want to make the code locale neutral. So hardcoding patterns is not > ideal. Skeltons resolves some problems, but I think it's still not > perfect. DateFormat keywords nicely hides the internal implementation, > but not flexible. > > When I worked on such feature, I found the combination of length > (redanduncy) and set of fields worked fine for API consumers. For > example, if you go for skelton approach, you still need to represent the > length in the skelton - such as "yyMMMd". But most of developers have no > good insight how the skelton pattern mapped to actual pattern, thus, do > not know what skelton pattern should be used in their code. In many > cases, they just want to specify calendar fields to be included and > approximate length of the final results. If such API takes desired field > set (for example, year + month + date) and length (short, medium, long), > developers can easily decide what to do. > > In my opinion, formatter APIs should support final patterns (no > programmatic process involved) for maximum customizability and well > abstracted keywords for convinience. > > -Yoshito > > icu...@li... wrote on 01/31/2008 06:55:06 PM: > > > The conceptual problem with creating from a pattern is that the > > result may look nothing like the input pattern. What we will do is > > map the input to a skeleton, see which fields differ between the two > > dates, and use that plus the skeleton to look up an appropriate > > result pattern in a set of preformed string (typically derived from > > the locale). That lookup has nothing to do with the input, so someone > could > > > > put in "yyyy-mmm-dd" > > > > and get back "1. Jan - 2. Fev 2008" > > > > Mark > > > > > On Jan 31, 2008 3:32 PM, xiaomei ji <xia...@gm...> wrote: > > Hi Yoshito, > > > > Looking at construction of DateIntervalFormat further, I think > > construct it using pattern ( which is passed by > > DateFormat/SimpleDateFormat ) is better than using skeleton. > > > > Although we format interval date by patterns, the skeleton on which > > we support interval date format is limited. > > For example, we probably wont support "hms" skeleton in interval > > patterns, as we think most users probably do not care about second > difference. > > > > For those not supported skeleton, the interval pattern fall backs to > > "single_full_pattern_of_date0" + separator + > "single_full_pattern_of_date1". > > So, we will need the single date/time format full pattern. > > > > As you mentioned in your earlier email, it is easy to get a skeleton > > from full pattern, but it is difficult to get a full pattern from > skeleton. > > So, I think it is better to construct DateIntervalFormat from > > (Simple)DateFormat which has a full pattern, and we derived skeleton > > there, looking into resource file for interval patterns of the > > skeleton, fall back to fallback pattern if not found. > > > > > > Thanks, > > Xiaomei > > > > > > > > > > > I like the skelton approach better than taking DateFormat as a > constructor > > argument. But, if that is the case, we want to have such factory method > > in DateFormat class for consistency. > > > > -Yoshito > > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > icu-design mailing list > > icu...@li... > > To Un/Subscribe: https://lists.sourceforge.net/lists/listinfo/icu-design > > > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > icu-design mailing list > > icu...@li... > > To Un/Subscribe: https://lists.sourceforge.net/lists/listinfo/icu-design > > > > > > > > -- > > Mark > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > icu-design mailing list > > icu...@li... > > To Un/Subscribe: https://lists.sourceforge.net/lists/listinfo/icu-design > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > icu-design mailing list > icu...@li... > To Un/Subscribe: https://lists.sourceforge.net/lists/listinfo/icu-design > |