Menu
▾
▴
icu-design
|
From: xiaomei j. <xia...@gm...> - 2008-01-17 22:50:34
|
Hi ICU designers,
I will be adding a date/time interval format in ICU.
It provides compact date/time format to represent from date1 to date2. For
example, the compact format to represent from "Jan 10, 2007" to "Jan 20,
2007" in en_US will be "Jan 10-20, 2007".
After discuss with Mark, Doug, and Markus, we proposed the following
design draft. And any feedbacks are very welcomed.
1. Introduce a new class: DateIntervalFormat as a sub-class of Format.
2. Since Format::format(const Formattable&, ...) formats an object, we will
introduce a new class: DateInterval, which contains 2 UDate as fields
representing date1 and date2.
DateIntervalFormat::format(const DateInterval*, .... ) formats DateInterval
object. And it parses UnicodeString into DateInterval object, although
initially we won't support parsing.
3. For ICU, we will provide an interval date/time format using
pattern-driven, instead of algorithm-driven.
And we will provide an algorithm-driven interval date/time format that we
can use in CLDR survey tool.
Following explains what are algorithm-driven and pattern-driven, and why we
are not supporting algorithm-driven in ICU.
Basically, algorithm-driven is to generate interval-date format by looking
for the initial and final identical substrings of 2 date formats.
The interval format will be composed of initial_identical_substring +
different_substring_from_date1 + date1_to_date2_separator +
different_substring_from_date2 + final_identical_string.
For example, for "Jan 10, 2007" and "Jan 20, 2007", the initial identical
substring is "Jan ", and the final identical substring is ", 2007". The
interval format will be: "Jan 10-20, 2007".
And the algorithm takes care of adjusting substring range based on the
largest different calendar fields.
For example, for "Mon, Jan 10, 2007" and "Mon, Feb 10, 2007", the initial
identical substring is "Mon, ", the final identical substring is " 10,
2007", and the different substrings are "Jan" and "Feb".
But the largest different calendar fields is month, which implies
day-of-week and day should also be part of the different substrings of date1
and date2.
The adjusted different substrings are "Mon, Jan 10" and "Mon, Feb 10", the
final identical substring is ", 2007". The interval format is "Mon, Jan 10 -
Mon, Feb 10, 2007".
We prototyped the algorithm in ICU4J, generated interval date/time format on
the 8 default date/time patterns, and send them to native speakers for
review.
>From our survey feedback of 24 languages, we found that algorithm does not
work (well) on the following patterns.
3.1. almost all time patterns.
For example, from 10:15 to 10:20, the interval format generated by algorithm
is 10:15-20, which is illegible.
3.2 almost all short date patterns.
For example, from 01/17/2008 to 01/18/2008, the interval format generated
by algorithm is 01/17-18/2008, which is illegible.
3.3 patterns with string literal, such as date patterns in Vietnamese, CJK.
3.4 patterns with non-separator punctuations, such as the dot "." in "d.
MMM, yyyy" in German ( the "." indicates the number is an ordinal number ).
Based on those feedback, we decided to use pattern-driven in ICU. But
provide algorithm for CLDR survey tool.
4. Logically, the patterns are mappings from (skeleton,
the_largest_different_calendar_field) to (date_interval_pattern).
For example, for a skeleton "dMMMy" in en_US, if the largest different
calendar field between date1 and date2 is "year", the date interval pattern
is "MMM d, yyyy - MMM d, yyyy", such as "Jan 10, 2007 - Jan 10, 2008".
If the largest different calendar field between date1 and date2 is "month",
the date interval pattern is "MMM d - MMM d, yyyy", such as "Jan 10 - Feb
10, 2007".
If the largest different calendar field between date1 and date2 is "day",
the date interval pattern is ""MMM d-d, yyyy", such as "Jan 10-20, 2007".
For a skeleton "MMMy", if the largest different calendar field between date1
and date2 is "month". the interval pattern is "MMM-MMM, yyyy", such as
"Jan-Feb, 2007".
Since we are implementing interval date/time format using pattern-driven,
then we will need to add interval patterns into resource files.
To represent above information, we will introduce another class:
DateIntervalInfo.
It is either constructed given a Locale, or constructed by user-supplied
list.
5. DateIntervalFormat will need the following information for correct
formatting: time zone, calendar type, pattern, date format symbols, and
DateIntervalInfo.
It will be constructed by the following 2 createInstance() member functions:
createInstance(const DateFormat*, const Locale&)
and
createInstance(const DateFormat*, const DateIntervalInfo* )
DateFormat object provides time zone, calendar type, pattern, and date
format symbols information for DateIntervalFormat.
Locale object provides the default date/time interval patterns. Or users can
replace the default interval patterns with their own patterns in
DateIntervalInfo object
Both of the above 2 functions will call a protected constructor
DateIntervalFormat(DateFormat &, const DateIntervalInfo & ) to construct
the DateIntervalFormat object.
Please be noted, the DateFormat object needs to be a SimpleDateFormat object
which has a pattern in it.
Also please be noted, if caller constructed SimpleDateFormat object by
providing a pattern, all the other information except the real pattern (
such as 'y', 'M', 'd', 'E', 'H', 'h', 'm' etc.) are thrown away when
convert the full pattern into skeleton.
For example, for English, if caller creates SimpleDateFormat object using
pattern "dd 'of' MMM 'in' yyyy", "of" and "in" will be thrown away, and the
converted skeleton is "ddMMMyyyy".
If day is different, the interval result will be "Jan 10-20, 2008", and it
won't be "10-20 of Jan in 2008".
Following is a code sample of the usage:
/* the date interval object which the DateIntervalFormat formats on
* and parses into
*/
DateInterval* dtInterval = new DateInterval(1000*3600*24, 1000*3600*24*2);
DateFormat* dtFmt = DateFormat::createDateInstance(DateFormat::FULL,
Locale("en", "GB", ""));
DateIntervalFormat* dtIntervalFmt =
DateIntervalFormat::createInstance(dtFmt, Locale("en", "GB", ""));
UnicodeString dateIntervalString;
UErrorCode status = U_ZERO_ERROR;
/* formatting */
dtIntervalFmt->format(dtInterval, dateIntervalString, status);
Thanks,
Xiaomei
|
|
From: George R. <gr...@us...> - 2008-01-18 04:12:33
|
The design sounds interesting. Can you provide a complete API proposal?=20 What are all the functions that are being proposed here? You can always=20 point to a draft API that you've checked into one of your branches. George Rhoten IBM Globalization Center of Competency/ICU San Jos=E9, CA, USA http://www.icu-project.org/ "xiaomei ji" <xia...@gm...>=20 Sent by: icu...@li... 01/17/2008 02:50 PM Please respond to icu...@li... To icu...@li... cc Subject [icu-design] Proposal of Interval Date/Time Format Hi ICU designers, I will be adding a date/time interval format in ICU. It provides compact date/time format to represent from date1 to date2. For = example, the compact format to represent from "Jan 10, 2007" to "Jan 20,=20 2007" in en=5FUS will be "Jan 10-20, 2007".=20 After discuss with Mark, Doug, and Markus, we proposed the following=20 design draft. And any feedbacks are very welcomed. 1. Introduce a new class: DateIntervalFormat as a sub-class of Format.=20 2. Since Format::format(const Formattable&, ...) formats an object, we=20 will introduce a new class: DateInterval, which contains 2 UDate as fields = representing date1 and date2.=20 DateIntervalFormat::format (const DateInterval*, .... ) formats DateInterval object. And it parses=20 UnicodeString into DateInterval object, although initially we won't=20 support parsing. 3. For ICU, we will provide an interval date/time format using=20 pattern-driven, instead of algorithm-driven.=20 And we will provide an algorithm-driven interval date/time format that we=20 can use in CLDR survey tool. Following explains what are algorithm-driven and pattern-driven, and why=20 we are not supporting algorithm-driven in ICU.=20 Basically, algorithm-driven is to generate interval-date format by looking = for the initial and final identical substrings of 2 date formats.=20 The interval format will be composed of initial=5Fidentical=5Fsubstring +=20 different=5Fsubstring=5Ffrom=5Fdate1 + date1=5Fto=5Fdate2=5Fseparator +=20 different=5Fsubstring=5Ffrom=5Fdate2 + final=5Fidentical=5Fstring.=20 For example, for "Jan 10, 2007" and "Jan 20, 2007", the initial identical=20 substring is "Jan ", and the final identical substring is ", 2007". The=20 interval format will be: "Jan 10-20, 2007".=20 And the algorithm takes care of adjusting substring range based on the=20 largest different calendar fields. For example, for "Mon, Jan 10, 2007" and "Mon, Feb 10, 2007", the initial=20 identical substring is "Mon, ", the final identical substring is " 10,=20 2007", and the different substrings are "Jan" and "Feb".=20 But the largest different calendar fields is month, which implies=20 day-of-week and day should also be part of the different substrings of=20 date1 and date2. The adjusted different substrings are "Mon, Jan 10" and "Mon, Feb 10", the = final identical substring is ", 2007". The interval format is "Mon, Jan 10 = - Mon, Feb 10, 2007".=20 We prototyped the algorithm in ICU4J, generated interval date/time format=20 on the 8 default date/time patterns, and send them to native speakers for=20 review. >From our survey feedback of 24 languages, we found that algorithm does not = work (well) on the following patterns.=20 3.1. almost all time patterns.=20 For example, from 10:15 to 10:20, the interval format generated by=20 algorithm is 10:15-20, which is illegible. 3.2 almost all short date patterns. For example, from 01/17/2008 to 01/18/2008, the interval format generated = by algorithm is 01/17-18/2008, which is illegible.=20 3.3 patterns with string literal, such as date patterns in Vietnamese,=20 CJK. 3.4 patterns with non-separator punctuations, such as the dot "." in "d.=20 MMM, yyyy" in German ( the "." indicates the number is an ordinal number=20 ).=20 Based on those feedback, we decided to use pattern-driven in ICU. But=20 provide algorithm for CLDR survey tool. 4. Logically, the patterns are mappings from (skeleton,=20 the=5Flargest=5Fdifferent=5Fcalendar=5Ffield) to (date=5Finterval=5Fpatter= n).=20 =20 For example, for a skeleton "dMMMy" in en=5FUS, if the largest different=20 calendar field between date1 and date2 is "year", the date interval=20 pattern is "MMM d, yyyy - MMM d, yyyy", such as "Jan 10, 2007 - Jan 10,=20 2008".=20 If the largest different calendar field between date1 and date2 is=20 "month", the date interval pattern is "MMM d - MMM d, yyyy", such as "Jan=20 10 - Feb 10, 2007". If the largest different calendar field between date1 and date2 is "day",=20 the date interval pattern is ""MMM d-d, yyyy", such as "Jan 10-20, 2007".=20 For a skeleton "MMMy", if the largest different calendar field between=20 date1 and date2 is "month". the interval pattern is "MMM-MMM, yyyy", such=20 as "Jan-Feb, 2007".=20 Since we are implementing interval date/time format using pattern-driven,=20 then we will need to add interval patterns into resource files.=20 To represent above information, we will introduce another class:=20 DateIntervalInfo. It is either constructed given a Locale, or constructed by user-supplied=20 list.=20 5. DateIntervalFormat will need the following information for correct=20 formatting: time zone, calendar type, pattern, date format symbols, and=20 DateIntervalInfo.=20 It will be constructed by the following 2 createInstance() member=20 functions:=20 createInstance(const DateFormat*, const Locale&) and createInstance(const DateFormat*, const DateIntervalInfo* )=20 DateFormat object provides time zone, calendar type, pattern, and date=20 format symbols information for DateIntervalFormat.=20 Locale object provides the default date/time interval patterns. Or users=20 can replace the default interval patterns with their own patterns in=20 DateIntervalInfo object Both of the above 2 functions will call a protected constructor=20 DateIntervalFormat(DateFormat &, const DateIntervalInfo & ) to construct=20 the DateIntervalFormat object.=20 Please be noted, the DateFormat object needs to be a SimpleDateFormat=20 object which has a pattern in it. Also please be noted, if caller constructed SimpleDateFormat object by=20 providing a pattern, all the other information except the real pattern (=20 such as 'y', 'M', 'd', 'E', 'H', 'h', 'm' etc.) are thrown away when=20 convert the full pattern into skeleton.=20 For example, for English, if caller creates SimpleDateFormat object using=20 pattern "dd 'of' MMM 'in' yyyy", "of" and "in" will be thrown away, and=20 the converted skeleton is "ddMMMyyyy".=20 If day is different, the interval result will be "Jan 10-20, 2008", and=20 it won't be "10-20 of Jan in 2008". Following is a code sample of the usage: /* the date interval object which the DateIntervalFormat formats on * and parses into=20 */ DateInterval* dtInterval =3D new DateInterval(1000*3600*24,=20 1000*3600*24*2); DateFormat* dtFmt =3D DateFormat::createDateInstance(DateFormat::FULL,=20 Locale("en", "GB", ""));=20 DateIntervalFormat* dtIntervalFmt =3D=20 DateIntervalFormat::createInstance(dtFmt, Locale("en", "GB", ""));=20 =20 UnicodeString dateIntervalString; UErrorCode status =3D U=5FZERO=5FERROR; /* formatting */ dtIntervalFmt->format(dtInterval, dateIntervalString, status); Thanks, Xiaomei=20 ------------------------------------------------------------------------- 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/ =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F icu-design mailing list icu...@li... To Un/Subscribe: https://lists.sourceforge.net/lists/listinfo/icu-design |
|
From: <yos...@us...> - 2008-01-21 15:51:29
|
Hi Xiomei, I actually developed such feature before joining the ICU project. I also tried algorithm-driven approach, but I ended up to define patterns for each locale for the reasons you pointed out. Anyway, I have some comments to your proposal. > 2. Since Format::format(const Formattable&, ...) formats an object, > we will introduce a new class: DateInterval, which contains 2 UDate > as fields representing date1 and date2. > DateIntervalFormat::format > (const DateInterval*, .... ) formats DateInterval object. And it > parses UnicodeString into DateInterval object, although initially we > won't support parsing. Do you have any good reasons to define a new object rather than making the API to take 2 UDate? > 3. For ICU, we will provide an interval date/time format using > pattern-driven, instead of algorithm-driven. > And we will provide an algorithm-driven interval date/time format > that we can use in CLDR survey tool. I agree that the implementation should be pattern-driven. But I still do not have good idea how the set of patterns defined for a locale. Can you explain the set of patterns in CLDR look like? > 3.3 patterns with string literal, such as date patterns in Vietnamese, CJK. > 3.4 patterns with non-separator punctuations, such as the dot "." in > "d. MMM, yyyy" in German ( the "." indicates the number is an > ordinal number ). > There is the same problem when parsing a pattern to make a sub-pattern (or super-pattern) done in DateFormatPatternGenerator. This is because a pattern does not have any structural information. I think pattern literals are categorized into 1. separator 2. field prefix 3. field suffix. Without having such information, parsing a pattern to make another pattern does not work well. In longer term, we may want to consider to re-define date format patterns to embed such information. > If the largest different calendar field between date1 and date2 is > "month", the date interval pattern is "MMM d - MMM d, yyyy", such as > "Jan 10 - Feb 10, 2007". > > If the largest different calendar field between date1 and date2 is > "day", the date interval pattern is ""MMM d-d, yyyy", such as "Jan > 10-20, 2007". How do you define the "largest" field? > For a skeleton "MMMy", if the largest different calendar field > between date1 and date2 is "month". the interval pattern is "MMM- > MMM, yyyy", such as "Jan-Feb, 2007". > > Since we are implementing interval date/time format using pattern- > driven, then we will need to add interval patterns into resource files. > To represent above information, we will introduce another class: > DateIntervalInfo. > > It is either constructed given a Locale, or constructed by user- > supplied list. I have a question here. If you want to supply the list of patterns, how do you represent the list? Because the formatter needs to switch applicable pattern by the larget different field, the set of patterns could be pretty complicated. For example, if a base pattern contains year, month, week of year, day of month, (day of week), hour, minute, the number of patterns required is 6 at maximum. > 5. DateIntervalFormat will need the following information for > correct formatting: time zone, calendar type, pattern, date format > symbols, and DateIntervalInfo. > > It will be constructed by the following 2 createInstance() member functions: > createInstance(const DateFormat*, const Locale&) > and > createInstance(const DateFormat*, const DateIntervalInfo* ) > > > DateFormat object provides time zone, calendar type, pattern, and > date format symbols information for DateIntervalFormat. > Locale object provides the default date/time interval patterns. Or > users can replace the default interval patterns with their own > patterns in DateIntervalInfo object > > Both of the above 2 functions will call a protected constructor > DateIntervalFormat(DateFormat &, const DateIntervalInfo & ) to > construct the DateIntervalFormat object. > > > Please be noted, the DateFormat object needs to be a > SimpleDateFormat object which has a pattern in it. > I do not like to use DateFormat here. As you addressed, DateFormat must be an instance of SimpleDateFormat with this design. Then, why don't you use SimpleDateFormat as the constructor argument? Actually, I prefer to define constructors similar to DateFormat's factory method. What you need to know is - 1. time zone 2. calendar type 3. format symbols 4. pattern(s) 5. number format If so, why don't you design the constructor to take these arguments? > Also please be noted, if caller constructed SimpleDateFormat object > by providing a pattern, all the other information except the real > pattern ( such as 'y', 'M', 'd', 'E', 'H', 'h', 'm' etc.) are > thrown away when convert the full pattern into skeleton. > > For example, for English, if caller creates SimpleDateFormat object > using pattern "dd 'of' MMM 'in' yyyy", "of" and "in" will be thrown > away, and the converted skeleton is "ddMMMyyyy". > If day is different, the interval result will be "Jan 10-20, 2008", > and it won't be "10-20 of Jan in 2008". This is really confusing. With this design, the implementation only collects date fields and ignores all others. Also, the logic used for transforming the skelton pattern into actual pattern is not well-explained. When I implemented such function in Java in my former project, I defined a factory method getInstance which takes exactly same arguments with DateFormat#getDateInstance (taking keywords such as DateFormat.Long, rather than actual pattern). I did not support time fields, because there was no such requirments in the project. I also did not allow callers to customize patterns, because I did not have good idea to make the design clean. -Yoshito |
|
From: xiaomei j. <xia...@gm...> - 2008-01-21 21:34:09
|
Hi Yoshito,
Thanks very much for your comments.
Please see my comments inline.
On 1/21/08, yos...@us... <yos...@us...> wrote:
> Hi Xiomei,
>
> I actually developed such feature before joining the ICU project. I also
> tried algorithm-driven approach, but I ended up to define patterns for
> each locale for the reasons you pointed out. Anyway, I have some comments
> to your proposal.
>
> > 2. Since Format::format(const Formattable&, ...) formats an object,
> > we will introduce a new class: DateInterval, which contains 2 UDate
> > as fields representing date1 and date2.
> > DateIntervalFormat::format
> > (const DateInterval*, .... ) formats DateInterval object. And it
> > parses UnicodeString into DateInterval object, although initially we
> > won't support parsing.
>
> Do you have any good reasons to define a new object rather than making the
> API to take 2 UDate?
DateIntervalFormat is one kind of format, and since Format::format()
formats one object,
we are thinking to define a new object which encapsulates 2 UDate in
DateIntervalFormat.
> > 3. For ICU, we will provide an interval date/time format using
> > pattern-driven, instead of algorithm-driven.
> > And we will provide an algorithm-driven interval date/time format
> > that we can use in CLDR survey tool.
>
> I agree that the implementation should be pattern-driven. But I still do
> not have good idea how the set of patterns defined for a locale. Can you
> explain the set of patterns in CLDR look like?
For English, it could be as following:
<calendars>
<calendar type="gregorian">
........
<dateIntervalFormats>
<dateIntervalFormatSkeleton type="EEEdMMMy">
<theLargestDifferentCalendarField type="year"
<pattern>EEE, MMM d, yyyy - EEE, MMM d, yyyy</pattern>
</theLargestDifferentCalendarField>
<theLargestDifferentCalendarField type="month">
<pattern>EEE, MMM d - EEE, MMM d, yyyy</pattern>
</theLargestDifferentCalendarField>
<theLargestDifferentCalendarField type="day"
<pattern>EEE, MMM d - EEE, MMM d, yyyy</pattern>
</theLargestDifferentCalendarField>
</dateIntervalFormatSkeleton>
.......
</dateIntervalFormats>
> > 3.3 patterns with string literal, such as date patterns in Vietnamese,
> CJK.
> > 3.4 patterns with non-separator punctuations, such as the dot "." in
> > "d. MMM, yyyy" in German ( the "." indicates the number is an
> > ordinal number ).
> >
>
> There is the same problem when parsing a pattern to make a sub-pattern (or
> super-pattern) done in DateFormatPatternGenerator. This is because a
> pattern does not have any structural information. I think pattern
> literals are categorized into 1. separator 2. field prefix 3. field
> suffix. Without having such information, parsing a pattern to make
> another pattern does not work well. In longer term, we may want to
> consider to re-define date format patterns to embed such information.
Agree.
> > If the largest different calendar field between date1 and date2 is
> > "month", the date interval pattern is "MMM d - MMM d, yyyy", such as
> > "Jan 10 - Feb 10, 2007".
> >
> > If the largest different calendar field between date1 and date2 is
> > "day", the date interval pattern is ""MMM d-d, yyyy", such as "Jan
> > 10-20, 2007".
>
> How do you define the "largest" field?
We probably won't support quarter and week, at least initially.
Then, the calendar fields can be divided into several levels, for example:
era -- the highest level;
year -- the next highest level;
month -- the 3rd;
day, day-of-week -- the 4th;
hour, hour-of-day -- the 5th; etc.
When compare the different calendar fields between 2 calendars, compare them
from the highest level to the lowest level to find the largest calendar
field.
For example: the largest calendar fields between "Jan 10, 2007" and "Feb 20,
2008" is year.
> > For a skeleton "MMMy", if the largest different calendar field
> > between date1 and date2 is "month". the interval pattern is "MMM-
> > MMM, yyyy", such as "Jan-Feb, 2007".
> >
> > Since we are implementing interval date/time format using pattern-
> > driven, then we will need to add interval patterns into resource files.
> > To represent above information, we will introduce another class:
> > DateIntervalInfo.
> >
> > It is either constructed given a Locale, or constructed by user-
> > supplied list.
>
> I have a question here. If you want to supply the list of patterns, how
> do you represent the list? Because the formatter needs to switch
> applicable pattern by the larget different field, the set of patterns
> could be pretty complicated. For example, if a base pattern contains
> year, month, week of year, day of month, (day of week), hour, minute, the
> number of patterns required is 6 at maximum.
I am thinking to have a function which takes key-value pair, the key is the
largest different calendar fields, the value is the pattern.
For example:
setIntervalPattern("month", "MMM d 'to' MMM d") sets interval pattern "MMM d
'to' MMM d" as the interval pattern when the largest different calendar
field is month.
This provides flexibility for powerful users.
> > 5. DateIntervalFormat will need the following information for
> > correct formatting: time zone, calendar type, pattern, date format
> > symbols, and DateIntervalInfo.
> >
> > It will be constructed by the following 2 createInstance() member
> functions:
>
> > createInstance(const DateFormat*, const Locale&)
> > and
> > createInstance(const DateFormat*, const DateIntervalInfo* )
> >
> >
> > DateFormat object provides time zone, calendar type, pattern, and
> > date format symbols information for DateIntervalFormat.
> > Locale object provides the default date/time interval patterns. Or
> > users can replace the default interval patterns with their own
> > patterns in DateIntervalInfo object
> >
> > Both of the above 2 functions will call a protected constructor
> > DateIntervalFormat(DateFormat &, const DateIntervalInfo & ) to
> > construct the DateIntervalFormat object.
> >
> >
> > Please be noted, the DateFormat object needs to be a
> > SimpleDateFormat object which has a pattern in it.
> >
>
> I do not like to use DateFormat here. As you addressed, DateFormat must
> be an instance of SimpleDateFormat with this design. Then, why don't you
> use SimpleDateFormat as the constructor argument?
The thought is:
User might construct a SimpleDateFormat object using DateFormat factory
method.
Instead of asking user to do downcast, we will take care of it.
> Actually, I prefer to
> define constructors similar to DateFormat's factory method. What you need
> to know is -
>
> 1. time zone
> 2. calendar type
> 3. format symbols
> 4. pattern(s)
> 5. number format
>
> If so, why don't you design the constructor to take these arguments?
It is a good idea to use the same factory method as that of DateFormat.
But we are trying to support interval format for not only the 4 default
date/time patterns defined in DateTimePattern. We are trying to support
interval patterns for the following 21 date skeletons and 6 time skeletons:
EEEEdMMMMy; dMMMMy; dMMMM; EEEEdMMMM; MMMMy; MMMM;
EEEdMMMy; dMMMy; dMMM; EEEdMMM; MMMy; MMM
EEEdMy; dMy; dM; EEEdM; My; M
d, EEEd, y;
hm; hmv; hmz; h; hv; hz;
We discussed whether we should construct DateIntervalFormat using full
pattern or skeleton. The advantage of constructing it using
(Simple)DateFormat is that (Simple)DateFormat provides all the above
5 elements so that DateIntervalFormat does not need to take care of by
duplicating the code.
Maybe construct DateIntervalFormat by skeleton directly (similar to
construct SimpleDateFormat by patterns directly) is better.
> > Also please be noted, if caller constructed SimpleDateFormat object
> > by providing a pattern, all the other information except the real
> > pattern ( such as 'y', 'M', 'd', 'E', 'H', 'h', 'm' etc.) are
> > thrown away when convert the full pattern into skeleton.
> >
> > For example, for English, if caller creates SimpleDateFormat object
> > using pattern "dd 'of' MMM 'in' yyyy", "of" and "in" will be thrown
> > away, and the converted skeleton is "ddMMMyyyy".
> > If day is different, the interval result will be "Jan 10-20, 2008",
> > and it won't be "10-20 of Jan in 2008".
>
> This is really confusing. With this design, the implementation only
> collects date fields and ignores all others. Also, the logic used for
> transforming the skelton pattern into actual pattern is not
> well-explained.
When I implemented such function in Java in my former project, I defined a
> factory method getInstance which takes exactly same arguments with
> DateFormat#getDateInstance (taking keywords such as DateFormat.Long,
> rather than actual pattern). I did not support time fields, because there
> was no such requirments in the project. I also did not allow callers to
> customize patterns, because I did not have good idea to make the design
> clean.
Thanks for your suggestion.
It is a good idea to use the same factory method as that of DateFormat.
But since we will support interval patterns for more skeletons, we probably
can not do the same way. But construct DateIntervalFormat from skeleton
directly might be better.
Thanks,
Xiaomei
> -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
>
|
|
From: <yos...@us...> - 2008-01-22 18:16:10
|
Thanks for your quick response.
I forgot to write one more questions in my previous message. - How does
the formatter work if all available fields have the exact same value? I
guess it should generate a single date string. But you did not mention
the case in your explanation. For example, if base pattern is "MMMM yyyy"
and two dates fall into a same month, then you want "January 2008".
I also added my response comments below.
-Yoshito
> Hi Yoshito,
>
> Thanks very much for your comments.
> Please see my comments inline.
>
>
> On 1/21/08, yos...@us... <yos...@us... >
wrote:
> Hi Xiomei,
>
> I actually developed such feature before joining the ICU project. I
also
> tried algorithm-driven approach, but I ended up to define patterns for
> each locale for the reasons you pointed out. Anyway, I have some
comments
> to your proposal.
>
> > 2. Since Format::format(const Formattable&, ...) formats an object,
> > we will introduce a new class: DateInterval, which contains 2 UDate
> > as fields representing date1 and date2.
> > DateIntervalFormat::format
> > (const DateInterval*, .... ) formats DateInterval object. And it
> > parses UnicodeString into DateInterval object, although initially we
> > won't support parsing.
>
> Do you have any good reasons to define a new object rather than making
the
> API to take 2 UDate?
>
> DateIntervalFormat is one kind of format, and since Format::format()
> formats one object,
> we are thinking to define a new object which encapsulates 2 UDate in
> DateIntervalFormat.
>
OK, it makes sense. Thanks.
> > 3. For ICU, we will provide an interval date/time format using
> > pattern-driven, instead of algorithm-driven.
> > And we will provide an algorithm-driven interval date/time format
> > that we can use in CLDR survey tool.
>
> I agree that the implementation should be pattern-driven. But I still
do
> not have good idea how the set of patterns defined for a locale. Can
you
> explain the set of patterns in CLDR look like?
>
> For English, it could be as following:
>
> <calendars>
> <calendar type="gregorian">
> ........
> <dateIntervalFormats>
> <dateIntervalFormatSkeleton type="EEEdMMMy">
> <theLargestDifferentCalendarField type="year"
> <pattern>EEE, MMM d, yyyy - EEE, MMM d,
yyyy</pattern>
> </theLargestDifferentCalendarField>
> <theLargestDifferentCalendarField type="month">
> <pattern>EEE, MMM d - EEE, MMM d, yyyy</pattern>
> </theLargestDifferentCalendarField>
> <theLargestDifferentCalendarField type="day"
> <pattern>EEE, MMM d - EEE, MMM d, yyyy</pattern>
> </theLargestDifferentCalendarField>
> </dateIntervalFormatSkeleton>
> .......
> </dateIntervalFormats>
>
A same field may be appeared twice in a single pattern. In your
suggestion, the first occurrence is for the first (older) date. I think
this assumption is always true, but logically not perfect. I guess we may
want to split a single pattern string into multiple strings. For example
-
[Your proposal]
<pattern>EEE, MMM d - EEE, MMM d, yyyy</pattern>
[Alternative proposal A]
<pattern date=1 ordinal=1>EEE, MMM d</pattern>
<pattern ordinal=2> - </pattern>
<pattern date=2 ordianl=3>EEE, MMM d, yyyy</pattern>
Or, you may embed the information for 1st/2nd date within a single pattern
like below -
[Alternative proposal B]
<pattern>{0,EEE}, MMM {0,d} - {1,EEE}, MMM {1,d}, yyyy</pattern>
> > If the largest different calendar field between date1 and date2 is
> > "month", the date interval pattern is "MMM d - MMM d, yyyy", such as
> > "Jan 10 - Feb 10, 2007".
> >
> > If the largest different calendar field between date1 and date2 is
> > "day", the date interval pattern is ""MMM d-d, yyyy", such as "Jan
> > 10-20, 2007".
>
> How do you define the "largest" field?
>
> We probably won't support quarter and week, at least initially.
>
> Then, the calendar fields can be divided into several levels, for
example:
> era -- the highest level;
> year -- the next highest level;
> month -- the 3rd;
> day, day-of-week -- the 4th;
> hour, hour-of-day -- the 5th; etc.
>
> When compare the different calendar fields between 2 calendars,
> compare them from the highest level to the lowest level to find the
> largest calendar field.
> For example: the largest calendar fields between "Jan 10, 2007" and
> "Feb 20, 2008" is year.
I quess we can reasonably define the order of calendar field -
era > year > quarter > month > week (of year/month) > hour (in day) >
minute > second > millisecond
Then, pattern data can define a desired pattern for least difference. For
example, you mentioned that most of people in the world do not want to use
hour/minute pattern like - "3:00 - 15". In this case, the pattern used
for different hours should be used for the result.
Thus, the algorith would be -
1. Find the least different calendar field in the input date pair.
2. Look up a pattern for the least different field in the locale pattern
repository.
3. If no match is found, look up a pattern for the next larger field.
Continue this operation until a match is found.
> > For a skeleton "MMMy", if the largest different calendar field
> > between date1 and date2 is "month". the interval pattern is "MMM-
> > MMM, yyyy", such as "Jan-Feb, 2007".
> >
> > Since we are implementing interval date/time format using pattern-
> > driven, then we will need to add interval patterns into resource
files.
> > To represent above information, we will introduce another class:
> > DateIntervalInfo.
> >
> > It is either constructed given a Locale, or constructed by user-
> > supplied list.
>
> I have a question here. If you want to supply the list of patterns, how
> do you represent the list? Because the formatter needs to switch
> applicable pattern by the larget different field, the set of patterns
> could be pretty complicated. For example, if a base pattern contains
> year, month, week of year, day of month, (day of week), hour, minute,
the
> number of patterns required is 6 at maximum.
>
> I am thinking to have a function which takes key-value pair, the key
> is the largest different calendar fields, the value is the pattern.
>
> For example:
> setIntervalPattern("month", "MMM d 'to' MMM d") sets interval
> pattern "MMM d 'to' MMM d" as the interval pattern when the largest
> different calendar field is month.
>
> This provides flexibility for powerful users.
OK. I think it works fine. By the way, when you specify "minimum field",
I guess we should use Calendar field constants, not strings like "month".
> > 5. DateIntervalFormat will need the following information for
> > correct formatting: time zone, calendar type, pattern, date format
> > symbols, and DateIntervalInfo.
> >
> > It will be constructed by the following 2 createInstance() member
> functions:
>
> > createInstance(const DateFormat*, const Locale&)
> > and
> > createInstance(const DateFormat*, const DateIntervalInfo* )
> >
> >
> > DateFormat object provides time zone, calendar type, pattern, and
> > date format symbols information for DateIntervalFormat.
> > Locale object provides the default date/time interval patterns. Or
> > users can replace the default interval patterns with their own
> > patterns in DateIntervalInfo object
> >
> > Both of the above 2 functions will call a protected constructor
> > DateIntervalFormat(DateFormat &, const DateIntervalInfo & ) to
> > construct the DateIntervalFormat object.
> >
> >
> > Please be noted, the DateFormat object needs to be a
> > SimpleDateFormat object which has a pattern in it.
> >
>
> I do not like to use DateFormat here. As you addressed, DateFormat must
> be an instance of SimpleDateFormat with this design. Then, why don't
you
> use SimpleDateFormat as the constructor argument?
>
> The thought is:
> User might construct a SimpleDateFormat object using DateFormat
> factory method.
> Instead of asking user to do downcast, we will take care of it.
>
>
>
> Actually, I prefer to
> define constructors similar to DateFormat's factory method. What you
need
> to know is -
>
> 1. time zone
> 2. calendar type
> 3. format symbols
> 4. pattern(s)
> 5. number format
>
> If so, why don't you design the constructor to take these arguments?
>
> It is a good idea to use the same factory method as that of DateFormat.
>
> But we are trying to support interval format for not only the 4
> default date/time patterns defined in DateTimePattern. We are trying
> to support interval patterns for the following 21 date skeletons and
> 6 time skeletons:
> EEEEdMMMMy; dMMMMy; dMMMM; EEEEdMMMM; MMMMy; MMMM;
> EEEdMMMy; dMMMy; dMMM; EEEdMMM; MMMy; MMM
> EEEdMy; dMy; dM; EEEdM; My; M
> d, EEEd, y;
> hm; hmv; hmz; h; hv; hz;
>
>
> We discussed whether we should construct DateIntervalFormat using
> full pattern or skeleton. The advantage of constructing it using
> (Simple)DateFormat is that (Simple)DateFormat provides all the above
> 5 elements so that DateIntervalFormat does not need to take care of
> by duplicating the code.
>
> Maybe construct DateIntervalFormat by skeleton directly (similar to
> construct SimpleDateFormat by patterns directly) is better.
>
> > Also please be noted, if caller constructed SimpleDateFormat object
> > by providing a pattern, all the other information except the real
> > pattern ( such as 'y', 'M', 'd', 'E', 'H', 'h', 'm' etc.) are
> > thrown away when convert the full pattern into skeleton.
> >
> > For example, for English, if caller creates SimpleDateFormat object
> > using pattern "dd 'of' MMM 'in' yyyy", "of" and "in" will be thrown
> > away, and the converted skeleton is "ddMMMyyyy".
> > If day is different, the interval result will be "Jan 10-20, 2008",
> > and it won't be "10-20 of Jan in 2008".
>
> This is really confusing. With this design, the implementation only
> collects date fields and ignores all others. Also, the logic used for
> transforming the skelton pattern into actual pattern is not
> well-explained.
> When I implemented such function in Java in my former project, I defined
a
> factory method getInstance which takes exactly same arguments with
> DateFormat#getDateInstance (taking keywords such as DateFormat.Long,
> rather than actual pattern). I did not support time fields, because
there
> was no such requirments in the project. I also did not allow callers to
> customize patterns, because I did not have good idea to make the design
> clean.
>
> Thanks for your suggestion.
> It is a good idea to use the same factory method as that of DateFormat.
> But since we will support interval patterns for more skeletons, we
> probably can not do the same way. But construct DateIntervalFormat
> from skeleton directly might be better.
>
I understand that style keywords in DateFormat are pretty limited, but
many users are good enough with them. So, no matter the class has other
constructors, I think it is a good idea to have it.
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
|
|
From: xiaomei j. <xia...@gm...> - 2008-01-22 19:58:15
|
Hi Yoshito,
Thanks for your comments again!
Please see my response below.
On Jan 22, 2008 10:17 AM, <yos...@us...> wrote:
> Thanks for your quick response.
>
> I forgot to write one more questions in my previous message. - How does
> the formatter work if all available fields have the exact same value? I
> guess it should generate a single date string. But you did not mention
> the case in your explanation. For example, if base pattern is "MMMM yyyy"
> and two dates fall into a same month, then you want "January 2008".
Yes, you are right.
>
>
> I also added my response comments below.
>
> -Yoshito
>
> > Hi Yoshito,
> >
> > Thanks very much for your comments.
> > Please see my comments inline.
> >
> >
> > On 1/21/08, yos...@us... <yos...@us... >
> wrote:
> > Hi Xiomei,
> >
> > I actually developed such feature before joining the ICU project. I
> also
> > tried algorithm-driven approach, but I ended up to define patterns for
> > each locale for the reasons you pointed out. Anyway, I have some
> comments
> > to your proposal.
> >
> > > 2. Since Format::format(const Formattable&, ...) formats an object,
> > > we will introduce a new class: DateInterval, which contains 2 UDate
> > > as fields representing date1 and date2.
> > > DateIntervalFormat::format
> > > (const DateInterval*, .... ) formats DateInterval object. And it
> > > parses UnicodeString into DateInterval object, although initially we
> > > won't support parsing.
> >
> > Do you have any good reasons to define a new object rather than making
> the
> > API to take 2 UDate?
> >
> > DateIntervalFormat is one kind of format, and since Format::format()
> > formats one object,
> > we are thinking to define a new object which encapsulates 2 UDate in
> > DateIntervalFormat.
> >
>
> OK, it makes sense. Thanks.
>
> > > 3. For ICU, we will provide an interval date/time format using
> > > pattern-driven, instead of algorithm-driven.
> > > And we will provide an algorithm-driven interval date/time format
> > > that we can use in CLDR survey tool.
> >
> > I agree that the implementation should be pattern-driven. But I still
> do
> > not have good idea how the set of patterns defined for a locale. Can
> you
> > explain the set of patterns in CLDR look like?
> >
> > For English, it could be as following:
> >
> > <calendars>
> > <calendar type="gregorian">
> > ........
> > <dateIntervalFormats>
> > <dateIntervalFormatSkeleton type="EEEdMMMy">
> > <theLargestDifferentCalendarField type="year"
> > <pattern>EEE, MMM d, yyyy - EEE, MMM d,
> yyyy</pattern>
> > </theLargestDifferentCalendarField>
> > <theLargestDifferentCalendarField type="month">
> > <pattern>EEE, MMM d - EEE, MMM d, yyyy</pattern>
> > </theLargestDifferentCalendarField>
> > <theLargestDifferentCalendarField type="day"
> > <pattern>EEE, MMM d - EEE, MMM d, yyyy</pattern>
> > </theLargestDifferentCalendarField>
> > </dateIntervalFormatSkeleton>
> > .......
> > </dateIntervalFormats>
> >
>
> A same field may be appeared twice in a single pattern. In your
> suggestion, the first occurrence is for the first (older) date. I think
> this assumption is always true, but logically not perfect. I guess we may
> want to split a single pattern string into multiple strings. For example
> -
>
> [Your proposal]
>
> <pattern>EEE, MMM d - EEE, MMM d, yyyy</pattern>
>
> [Alternative proposal A]
>
> <pattern date=1 ordinal=1>EEE, MMM d</pattern>
> <pattern ordinal=2> - </pattern>
> <pattern date=2 ordianl=3>EEE, MMM d, yyyy</pattern>
>
> Or, you may embed the information for 1st/2nd date within a single pattern
> like below -
>
> [Alternative proposal B]
> <pattern>{0,EEE}, MMM {0,d} - {1,EEE}, MMM {1,d}, yyyy</pattern>
I see what you mean.
Let me discuss the format with Mark and Doug, and I will let you know.
>
> > > If the largest different calendar field between date1 and date2 is
> > > "month", the date interval pattern is "MMM d - MMM d, yyyy", such as
> > > "Jan 10 - Feb 10, 2007".
> > >
> > > If the largest different calendar field between date1 and date2 is
> > > "day", the date interval pattern is ""MMM d-d, yyyy", such as "Jan
> > > 10-20, 2007".
> >
> > How do you define the "largest" field?
> >
> > We probably won't support quarter and week, at least initially.
> >
> > Then, the calendar fields can be divided into several levels, for
> example:
> > era -- the highest level;
> > year -- the next highest level;
> > month -- the 3rd;
> > day, day-of-week -- the 4th;
> > hour, hour-of-day -- the 5th; etc.
> >
> > When compare the different calendar fields between 2 calendars,
> > compare them from the highest level to the lowest level to find the
> > largest calendar field.
> > For example: the largest calendar fields between "Jan 10, 2007" and
> > "Feb 20, 2008" is year.
>
> I quess we can reasonably define the order of calendar field -
>
> era > year > quarter > month > week (of year/month) > hour (in day) >
> minute > second > millisecond
>
> Then, pattern data can define a desired pattern for least difference. For
> example, you mentioned that most of people in the world do not want to use
> hour/minute pattern like - "3:00 - 15". In this case, the pattern used
> for different hours should be used for the result.
>
> Thus, the algorith would be -
>
> 1. Find the least different calendar field in the input date pair.
> 2. Look up a pattern for the least different field in the locale pattern
> repository.
> 3. If no match is found, look up a pattern for the next larger field.
> Continue this operation until a match is found.
I do not quite understand the algorithm here.
For example, given 2 dates "Jan 10, 2007" and "Feb 20, 2008",
the least different calendar field is day for step 1,
and the pattern for the least different field is "MMM d-d, yyyy" from step
2, a match found, so, the final result is "Jan 10-20, 2007".
The pattern data defines a desired pattern for *largest* difference unit.
To solve the case of ""3:00 - 15", for skeleton "hm",
the interval pattern when hour is different is "hh:mm-hh:mm",
and the interval pattern when minute is different is the same:
"hh:mm-hh:mm".
>
> > > For a skeleton "MMMy", if the largest different calendar field
> > > between date1 and date2 is "month". the interval pattern is "MMM-
> > > MMM, yyyy", such as "Jan-Feb, 2007".
> > >
> > > Since we are implementing interval date/time format using pattern-
> > > driven, then we will need to add interval patterns into resource
> files.
> > > To represent above information, we will introduce another class:
> > > DateIntervalInfo.
> > >
> > > It is either constructed given a Locale, or constructed by user-
> > > supplied list.
> >
> > I have a question here. If you want to supply the list of patterns, how
>
> > do you represent the list? Because the formatter needs to switch
> > applicable pattern by the larget different field, the set of patterns
> > could be pretty complicated. For example, if a base pattern contains
> > year, month, week of year, day of month, (day of week), hour, minute,
> the
> > number of patterns required is 6 at maximum.
> >
> > I am thinking to have a function which takes key-value pair, the key
> > is the largest different calendar fields, the value is the pattern.
> >
> > For example:
> > setIntervalPattern("month", "MMM d 'to' MMM d") sets interval
> > pattern "MMM d 'to' MMM d" as the interval pattern when the largest
> > different calendar field is month.
> >
> > This provides flexibility for powerful users.
>
> OK. I think it works fine. By the way, when you specify "minimum field",
> I guess we should use Calendar field constants, not strings like "month".
Yes, you are right.
Underlying, we will use those field constants.
But this is a public API, meant for powerful users to create their own
interval patterns and use them to create DateIntervalFormat.
So, I think we need to use string literals here and document them well.
>
> > > 5. DateIntervalFormat will need the following information for
> > > correct formatting: time zone, calendar type, pattern, date format
> > > symbols, and DateIntervalInfo.
> > >
> > > It will be constructed by the following 2 createInstance() member
> > functions:
> >
> > > createInstance(const DateFormat*, const Locale&)
> > > and
> > > createInstance(const DateFormat*, const DateIntervalInfo* )
> > >
> > >
> > > DateFormat object provides time zone, calendar type, pattern, and
> > > date format symbols information for DateIntervalFormat.
> > > Locale object provides the default date/time interval patterns. Or
> > > users can replace the default interval patterns with their own
> > > patterns in DateIntervalInfo object
> > >
> > > Both of the above 2 functions will call a protected constructor
> > > DateIntervalFormat(DateFormat &, const DateIntervalInfo & ) to
> > > construct the DateIntervalFormat object.
> > >
> > >
> > > Please be noted, the DateFormat object needs to be a
> > > SimpleDateFormat object which has a pattern in it.
> > >
> >
> > I do not like to use DateFormat here. As you addressed, DateFormat must
>
> > be an instance of SimpleDateFormat with this design. Then, why don't
> you
> > use SimpleDateFormat as the constructor argument?
> >
> > The thought is:
> > User might construct a SimpleDateFormat object using DateFormat
> > factory method.
> > Instead of asking user to do downcast, we will take care of it.
> >
> >
> >
> > Actually, I prefer to
> > define constructors similar to DateFormat's factory method. What you
> need
> > to know is -
> >
> > 1. time zone
> > 2. calendar type
> > 3. format symbols
> > 4. pattern(s)
> > 5. number format
> >
> > If so, why don't you design the constructor to take these arguments?
> >
> > It is a good idea to use the same factory method as that of DateFormat.
> >
> > But we are trying to support interval format for not only the 4
> > default date/time patterns defined in DateTimePattern. We are trying
> > to support interval patterns for the following 21 date skeletons and
> > 6 time skeletons:
> > EEEEdMMMMy; dMMMMy; dMMMM; EEEEdMMMM; MMMMy; MMMM;
> > EEEdMMMy; dMMMy; dMMM; EEEdMMM; MMMy; MMM
> > EEEdMy; dMy; dM; EEEdM; My; M
> > d, EEEd, y;
> > hm; hmv; hmz; h; hv; hz;
> >
> >
> > We discussed whether we should construct DateIntervalFormat using
> > full pattern or skeleton. The advantage of constructing it using
> > (Simple)DateFormat is that (Simple)DateFormat provides all the above
> > 5 elements so that DateIntervalFormat does not need to take care of
> > by duplicating the code.
> >
> > Maybe construct DateIntervalFormat by skeleton directly (similar to
> > construct SimpleDateFormat by patterns directly) is better.
> >
> > > Also please be noted, if caller constructed SimpleDateFormat object
> > > by providing a pattern, all the other information except the real
> > > pattern ( such as 'y', 'M', 'd', 'E', 'H', 'h', 'm' etc.) are
> > > thrown away when convert the full pattern into skeleton.
> > >
> > > For example, for English, if caller creates SimpleDateFormat object
> > > using pattern "dd 'of' MMM 'in' yyyy", "of" and "in" will be thrown
> > > away, and the converted skeleton is "ddMMMyyyy".
> > > If day is different, the interval result will be "Jan 10-20, 2008",
> > > and it won't be "10-20 of Jan in 2008".
> >
> > This is really confusing. With this design, the implementation only
> > collects date fields and ignores all others. Also, the logic used for
> > transforming the skelton pattern into actual pattern is not
> > well-explained.
> > When I implemented such function in Java in my former project, I defined
> a
> > factory method getInstance which takes exactly same arguments with
> > DateFormat#getDateInstance (taking keywords such as DateFormat.Long,
> > rather than actual pattern). I did not support time fields, because
> there
> > was no such requirments in the project. I also did not allow callers to
>
> > customize patterns, because I did not have good idea to make the design
> > clean.
> >
> > Thanks for your suggestion.
> > It is a good idea to use the same factory method as that of DateFormat.
> > But since we will support interval patterns for more skeletons, we
> > probably can not do the same way. But construct DateIntervalFormat
> > from skeleton directly might be better.
> >
>
> I understand that style keywords in DateFormat are pretty limited, but
> many users are good enough with them. So, no matter the class has other
> constructors, I think it is a good idea to have it.
I agree. And I will include them ( if no one objects ).
>
>
> 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.
Let me discuss this with Mark and Doug, and I will let you know.
Thanks,
Xiaomei
>
> -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
>
|
|
From: xiaomei j. <xia...@gm...> - 2008-01-23 01:06:34
|
Hi Yoshito,
Please see my 2 extra comments below.
Thanks,
Xiaomei
> > 3. For ICU, we will provide an interval date/time format using
> > > > pattern-driven, instead of algorithm-driven.
> > > > And we will provide an algorithm-driven interval date/time format
> > > > that we can use in CLDR survey tool.
> > >
> > > I agree that the implementation should be pattern-driven. But I still
> >
> > do
> > > not have good idea how the set of patterns defined for a locale. Can
> > you
> > > explain the set of patterns in CLDR look like?
> > >
> > > For English, it could be as following:
> > >
> > > <calendars>
> > > <calendar type="gregorian">
> > > ........
> > > <dateIntervalFormats>
> > > <dateIntervalFormatSkeleton type="EEEdMMMy">
> > > <theLargestDifferentCalendarField type="year"
> > > <pattern>EEE, MMM d, yyyy - EEE, MMM d,
> > yyyy</pattern>
> > > </theLargestDifferentCalendarField>
> > > <theLargestDifferentCalendarField type="month">
> > > <pattern>EEE, MMM d - EEE, MMM d, yyyy</pattern>
> > > </theLargestDifferentCalendarField>
> > > <theLargestDifferentCalendarField type="day"
> > > <pattern>EEE, MMM d - EEE, MMM d, yyyy</pattern>
> > > </theLargestDifferentCalendarField>
> > > </dateIntervalFormatSkeleton>
> > > .......
> > > </dateIntervalFormats>
> > >
> >
> > A same field may be appeared twice in a single pattern. In your
> > suggestion, the first occurrence is for the first (older) date. I think
> > this assumption is always true, but logically not perfect. I guess we
> > may
> > want to split a single pattern string into multiple strings. For
> > example
> > -
> >
> > [Your proposal]
> >
> > <pattern>EEE, MMM d - EEE, MMM d, yyyy</pattern>
> >
> > [Alternative proposal A]
> >
> > <pattern date=1 ordinal=1>EEE, MMM d</pattern>
> > <pattern ordinal=2> - </pattern>
> > <pattern date=2 ordianl=3>EEE, MMM d, yyyy</pattern>
> >
> > Or, you may embed the information for 1st/2nd date within a single
> > pattern
> > like below -
> >
> > [Alternative proposal B]
> > <pattern>{0,EEE}, MMM {0,d} - {1,EEE}, MMM {1,d}, yyyy</pattern>
>
>
> I see what you mean.
> Let me discuss the format with Mark and Doug, and I will let you know.
>
>
Thinking of we allow users to provide the interval patterns as well, I
prefer alternative B, if we want to make it logically perfect.
>
>
> > > > For a skeleton "MMMy", if the largest different calendar field
> > > > between date1 and date2 is "month". the interval pattern is "MMM-
> > > > MMM, yyyy", such as "Jan-Feb, 2007".
> > > >
> > > > Since we are implementing interval date/time format using pattern-
> > > > driven, then we will need to add interval patterns into resource
> > files.
> > > > To represent above information, we will introduce another class:
> > > > DateIntervalInfo.
> > > >
> > > > It is either constructed given a Locale, or constructed by user-
> > > > supplied list.
> > >
> > > I have a question here. If you want to supply the list of patterns,
> > how
> >
> > > do you represent the list? Because the formatter needs to switch
> > > applicable pattern by the larget different field, the set of patterns
> > > could be pretty complicated. For example, if a base pattern contains
> > > year, month, week of year, day of month, (day of week), hour, minute,
> > the
> > > number of patterns required is 6 at maximum.
> > >
> > > I am thinking to have a function which takes key-value pair, the key
> > > is the largest different calendar fields, the value is the pattern.
> > >
> > > For example:
> > > setIntervalPattern("month", "MMM d 'to' MMM d") sets interval
> > > pattern "MMM d 'to' MMM d" as the interval pattern when the largest
> > > different calendar field is month.
> > >
> > > This provides flexibility for powerful users.
> >
> > OK. I think it works fine. By the way, when you specify "minimum
> > field",
> > I guess we should use Calendar field constants, not strings like
> > "month".
>
>
> Yes, you are right.
> Underlying, we will use those field constants.
>
> But this is a public API, meant for powerful users to create their own
> interval patterns and use them to create DateIntervalFormat.
> So, I think we need to use string literals here and document them well.
>
I think you have a point here.
I will make 2 public APIs, one takes string as argument, the other takes
Calendar field constants as argument.
|
|
From: xiaomei j. <xia...@gm...> - 2008-01-31 23:33:00
|
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 > |
|
From: Mark D. <mar...@ic...> - 2008-01-31 23:55:04
|
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 |
|
From: <yos...@us...> - 2008-02-01 15:56:17
|
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 |
|
From: xiaomei j. <xia...@gm...> - 2008-02-02 05:26:59
|
Hi Yoshito, Thanks for your comments again! Please see my comments below. 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. If I understand you correctly, we have the same thought. We plan to define a set of const strings to represent the skeleton. ( I will send another email about our proposal on 2 issues we talked about). It actually is not a skeleton -- in the sense that it does not depend on individual pattern's length. It is more as a skeleton takes desired field and short/medium/long length. for example, skeleton EEEEdMMMMy takes desired field and full length. For English, the interval pattern when month is different is "EEEE, MMMM d - EEEE, MMMM d, yyyy", derived from date full pattern. skeleton dMMM takes month/day and medium length. skeleton My takes month/year and short format length, the interval pattern when month is different is "M/yy - M/yy", derived from date short pattern. Please let me know if I mis-understood you. Thanks, Xiaomei 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 > |
|
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
>
|
|
From: Merle T. <ten...@gm...> - 2008-01-21 20:17:19
|
Xiaomei,
Your proposal sounds great. Let me just point out that you will probably
want to parameterize the range separator character. Some folks may want to
use a hyphen for everything. Typographers will want to use an en dash in
expressions like "Jan 10-20, 2007". And some cultures will prefer an em
dash or swung dash. Also, some cultures will wish to put a space before
and/or after the separator.
This is further complicated by the fact that size of the parallel elements
on either side of the separator inside the entire range expression may
influence the separator and spacing to be chosen. For example, in "Jan
10-20, 2008" the parallel conjuncts are days of the month, so most people
are fine with a hyphen or an en dash and no surrounding space. In "Jan 10,
2008 -- Jan 9, 2009" most people would prefer two hyphens, an en dash, or an
em dash, most likely surrounded by spaces. A single hyphen with no
surrounding spaces really doesn't cut it for full date ranges.
I think the way to handle this is to allow different separator
specifications for different sizes of parallel conjuncts. I'm guessing that
parameters for conjoined (a) days, (b) months and days, and (c) full dates
ought to do it. Exception: if date formats include days of the week, and an
interval falls completely witin one month and year, then the interval
formatting should be forced into the (b) case.
It gets a little (not a lot) more complicated if you allow time intervals of
(d) months, but no days or years, or (e) months and years, but no days, or
(f) years, but no months or days. I didn't see anything about partial date
intervals in the spec, so maybe this is not issue today. That said, if we
expect to handle partial date intervals in some future API, we might want to
give a thought as to how we would handle the interval separators for them.
I think we can design something for full date intervals that could be
extended naturally to handle partial data intervals like "Oct - Dec 2008".
Merle
On Jan 17, 2008 2:50 PM, xiaomei ji <xia...@gm...> wrote:
> Hi ICU designers,
>
> I will be adding a date/time interval format in ICU.
>
> It provides compact date/time format to represent from date1 to date2. For
> example, the compact format to represent from "Jan 10, 2007" to "Jan 20,
> 2007" in en_US will be "Jan 10-20, 2007".
>
> After discuss with Mark, Doug, and Markus, we proposed the following
> design draft. And any feedbacks are very welcomed.
>
> 1. Introduce a new class: DateIntervalFormat as a sub-class of Format.
>
> 2. Since Format::format(const Formattable&, ...) formats an object, we
> will introduce a new class: DateInterval, which contains 2 UDate as fields
> representing date1 and date2.
> DateIntervalFormat::format (const DateInterval*, .... ) formats
> DateInterval object. And it parses UnicodeString into DateInterval object,
> although initially we won't support parsing.
>
> 3. For ICU, we will provide an interval date/time format using
> pattern-driven, instead of algorithm-driven.
> And we will provide an algorithm-driven interval date/time format that we
> can use in CLDR survey tool.
>
> Following explains what are algorithm-driven and pattern-driven, and why
> we are not supporting algorithm-driven in ICU.
>
> Basically, algorithm-driven is to generate interval-date format by looking
> for the initial and final identical substrings of 2 date formats.
> The interval format will be composed of initial_identical_substring +
> different_substring_from_date1 + date1_to_date2_separator +
> different_substring_from_date2 + final_identical_string.
>
> For example, for "Jan 10, 2007" and "Jan 20, 2007", the initial identical
> substring is "Jan ", and the final identical substring is ", 2007". The
> interval format will be: "Jan 10-20, 2007".
>
> And the algorithm takes care of adjusting substring range based on the
> largest different calendar fields.
>
> For example, for "Mon, Jan 10, 2007" and "Mon, Feb 10, 2007", the initial
> identical substring is "Mon, ", the final identical substring is " 10,
> 2007", and the different substrings are "Jan" and "Feb".
> But the largest different calendar fields is month, which implies
> day-of-week and day should also be part of the different substrings of date1
> and date2.
> The adjusted different substrings are "Mon, Jan 10" and "Mon, Feb 10", the
> final identical substring is ", 2007". The interval format is "Mon, Jan 10 -
> Mon, Feb 10, 2007".
>
> We prototyped the algorithm in ICU4J, generated interval date/time format
> on the 8 default date/time patterns, and send them to native speakers for
> review.
>
> From our survey feedback of 24 languages, we found that algorithm does not
> work (well) on the following patterns.
>
> 3.1. almost all time patterns.
> For example, from 10:15 to 10:20, the interval format generated by
> algorithm is 10:15-20, which is illegible.
>
> 3.2 almost all short date patterns.
> For example, from 01/17/2008 to 01/18/2008, the interval format generated
> by algorithm is 01/17-18/2008, which is illegible.
>
> 3.3 patterns with string literal, such as date patterns in Vietnamese,
> CJK.
> 3.4 patterns with non-separator punctuations, such as the dot "." in "d.
> MMM, yyyy" in German ( the "." indicates the number is an ordinal number ).
>
>
> Based on those feedback, we decided to use pattern-driven in ICU. But
> provide algorithm for CLDR survey tool.
>
>
>
> 4. Logically, the patterns are mappings from (skeleton,
> the_largest_different_calendar_field) to (date_interval_pattern).
>
> For example, for a skeleton "dMMMy" in en_US, if the largest different
> calendar field between date1 and date2 is "year", the date interval pattern
> is "MMM d, yyyy - MMM d, yyyy", such as "Jan 10, 2007 - Jan 10, 2008".
>
> If the largest different calendar field between date1 and date2 is
> "month", the date interval pattern is "MMM d - MMM d, yyyy", such as "Jan 10
> - Feb 10, 2007".
>
> If the largest different calendar field between date1 and date2 is "day",
> the date interval pattern is ""MMM d-d, yyyy", such as "Jan 10-20, 2007".
>
> For a skeleton "MMMy", if the largest different calendar field between
> date1 and date2 is "month". the interval pattern is "MMM-MMM, yyyy", such as
> "Jan-Feb, 2007".
> Since we are implementing interval date/time format using pattern-driven,
> then we will need to add interval patterns into resource files.
> To represent above information, we will introduce another class:
> DateIntervalInfo.
>
> It is either constructed given a Locale, or constructed by user-supplied
> list.
>
>
> 5. DateIntervalFormat will need the following information for correct
> formatting: time zone, calendar type, pattern, date format symbols, and
> DateIntervalInfo.
>
> It will be constructed by the following 2 createInstance() member
> functions:
>
> createInstance(const DateFormat*, const Locale&)
> and
> createInstance(const DateFormat*, const DateIntervalInfo* )
>
> DateFormat object provides time zone, calendar type, pattern, and date
> format symbols information for DateIntervalFormat.
> Locale object provides the default date/time interval patterns. Or users
> can replace the default interval patterns with their own patterns in
> DateIntervalInfo object
>
> Both of the above 2 functions will call a protected constructor
> DateIntervalFormat(DateFormat &, const DateIntervalInfo & ) to construct
> the DateIntervalFormat object.
>
>
> Please be noted, the DateFormat object needs to be a SimpleDateFormat
> object which has a pattern in it.
>
> Also please be noted, if caller constructed SimpleDateFormat object by
> providing a pattern, all the other information except the real pattern (
> such as 'y', 'M', 'd', 'E', 'H', 'h', 'm' etc.) are thrown away when
> convert the full pattern into skeleton.
>
> For example, for English, if caller creates SimpleDateFormat object using
> pattern "dd 'of' MMM 'in' yyyy", "of" and "in" will be thrown away, and the
> converted skeleton is "ddMMMyyyy".
> If day is different, the interval result will be "Jan 10-20, 2008", and
> it won't be "10-20 of Jan in 2008".
>
>
>
>
> Following is a code sample of the usage:
>
> /* the date interval object which the DateIntervalFormat formats on
> * and parses into
> */
> DateInterval* dtInterval = new DateInterval(1000*3600*24,
> 1000*3600*24*2);
>
> DateFormat* dtFmt = DateFormat::createDateInstance(DateFormat::FULL,
> Locale("en", "GB", ""));
>
> DateIntervalFormat* dtIntervalFmt =
> DateIntervalFormat::createInstance(dtFmt, Locale("en", "GB", ""));
>
> UnicodeString dateIntervalString;
> UErrorCode status = U_ZERO_ERROR;
>
> /* formatting */
> dtIntervalFmt->format(dtInterval, dateIntervalString, status);
>
>
>
> Thanks,
> Xiaomei
>
> -------------------------------------------------------------------------
> 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
>
|
|
From: xiaomei j. <xia...@gm...> - 2008-01-21 21:52:30
|
Hi Merle,
Thanks for your comments.
Please see my comments inline.
On 1/21/08, Merle Tenney <ten...@gm...> wrote:
>
> Xiaomei,
>
> Your proposal sounds great. Let me just point out that you will probably
> want to parameterize the range separator character. Some folks may want to
> use a hyphen for everything. Typographers will want to use an en dash in
> expressions like "Jan 10-20, 2007". And some cultures will prefer an em
> dash or swung dash. Also, some cultures will wish to put a space before
> and/or after the separator.
>
Yes. We have interval patterns defined in resource files. Some locales have
their preferred separators other than en dash in their interval patterns.
> This is further complicated by the fact that size of the parallel elements
> on either side of the separator inside the entire range expression may
> influence the separator and spacing to be chosen. For example, in "Jan
> 10-20, 2008" the parallel conjuncts are days of the month, so most people
> are fine with a hyphen or an en dash and no surrounding space. In "Jan 10,
> 2008 -- Jan 9, 2009" most people would prefer two hyphens, an en dash, or an
> em dash, most likely surrounded by spaces. A single hyphen with no
> surrounding spaces really doesn't cut it for full date ranges.
>
Yes. We use pattern-driven for date interval format, and the interval
patterns are defined in resource files. The separators and whether there are
spaces around separators are all taken care by the interval patterns defined
in resource files.
My initial draft is using "-" as separators for all locales. If "-"
separates one item, such as in "Jan 10-20, 2008", there is no spaces around
"-". Otherwise, there is spaces around "-", such as in "Jan 10, 2008 - Jan
9, 2009".
I've send the generated interval format for native speakers for review
and changed the separators/spaces-around-separators according to their
feedback.
> I think the way to handle this is to allow different separator
> specifications for different sizes of parallel conjuncts. I'm guessing that
> parameters for conjoined (a) days, (b) months and days, and (c) full dates
> ought to do it. Exception: if date formats include days of the week, and an
> interval falls completely witin one month and year, then the interval
> formatting should be forced into the (b) case.
>
That is a good suggestion.
I only used the number of items a separator separates as a factor.
> It gets a little (not a lot) more complicated if you allow time intervals
> of (d) months, but no days or years, or (e) months and years, but no days,
> or (f) years, but no months or days. I didn't see anything about partial
> date intervals in the spec, so maybe this is not issue today. That said, if
> we expect to handle partial date intervals in some future API, we might want
> to give a thought as to how we would handle the interval separators for
> them. I think we can design something for full date intervals that could be
> extended naturally to handle partial data intervals like "Oct - Dec 2008".
>
We actually try to support partial date intervals.
We are trying to support the following skeletons:
EEEEdMMMMy; dMMMMy; dMMMM; EEEEdMMMM; MMMMy; MMMM;
EEEdMMMy; dMMMy; dMMM; EEEdMMM; MMMy; MMM
EEEdMy; dMy; dM; EEEdM; My; M
d, EEEd, y;
hm; hmv; hmz; h; hv; hz;
And I agree, the rule we designed for full date intervals should can be
extended naturally to handle partial date intervals.
Thanks,
Xiaomei
> Merle
>
> On Jan 17, 2008 2:50 PM, xiaomei ji <xia...@gm...> wrote:
>
> > Hi ICU designers,
> >
> > I will be adding a date/time interval format in ICU.
> >
> > It provides compact date/time format to represent from date1 to date2.
> > For example, the compact format to represent from "Jan 10, 2007" to "Jan 20,
> > 2007" in en_US will be "Jan 10-20, 2007".
> >
> > After discuss with Mark, Doug, and Markus, we proposed the following
> > design draft. And any feedbacks are very welcomed.
> >
> > 1. Introduce a new class: DateIntervalFormat as a sub-class of Format.
> >
> > 2. Since Format::format(const Formattable&, ...) formats an object, we
> > will introduce a new class: DateInterval, which contains 2 UDate as fields
> > representing date1 and date2.
> >
> > DateIntervalFormat::format (const DateInterval*, .... ) formats
> > DateInterval object. And it parses UnicodeString into DateInterval object,
> > although initially we won't support parsing.
> >
> > 3. For ICU, we will provide an interval date/time format using
> > pattern-driven, instead of algorithm-driven.
> > And we will provide an algorithm-driven interval date/time format that
> > we can use in CLDR survey tool.
> >
> > Following explains what are algorithm-driven and pattern-driven, and why
> > we are not supporting algorithm-driven in ICU.
> >
> > Basically, algorithm-driven is to generate interval-date format by
> > looking for the initial and final identical substrings of 2 date formats.
> > The interval format will be composed of initial_identical_substring +
> > different_substring_from_date1 + date1_to_date2_separator +
> > different_substring_from_date2 + final_identical_string.
> >
> > For example, for "Jan 10, 2007" and "Jan 20, 2007", the initial
> > identical substring is "Jan ", and the final identical substring is ",
> > 2007". The interval format will be: "Jan 10-20, 2007".
> >
> > And the algorithm takes care of adjusting substring range based on the
> > largest different calendar fields.
> >
> > For example, for "Mon, Jan 10, 2007" and "Mon, Feb 10, 2007", the
> > initial identical substring is "Mon, ", the final identical substring is "
> > 10, 2007", and the different substrings are "Jan" and "Feb".
> > But the largest different calendar fields is month, which implies
> > day-of-week and day should also be part of the different substrings of date1
> > and date2.
> > The adjusted different substrings are "Mon, Jan 10" and "Mon, Feb 10",
> > the final identical substring is ", 2007". The interval format is "Mon, Jan
> > 10 - Mon, Feb 10, 2007".
> >
> > We prototyped the algorithm in ICU4J, generated interval date/time
> > format on the 8 default date/time patterns, and send them to native speakers
> > for review.
> >
> > From our survey feedback of 24 languages, we found that algorithm does
> > not work (well) on the following patterns.
> >
> > 3.1. almost all time patterns.
> > For example, from 10:15 to 10:20, the interval format generated by
> > algorithm is 10:15-20, which is illegible.
> >
> > 3.2 almost all short date patterns.
> > For example, from 01/17/2008 to 01/18/2008, the interval format
> > generated by algorithm is 01/17-18/2008, which is illegible.
> >
> > 3.3 patterns with string literal, such as date patterns in Vietnamese,
> > CJK.
> > 3.4 patterns with non-separator punctuations, such as the dot "." in "d.
> > MMM, yyyy" in German ( the "." indicates the number is an ordinal number ).
> >
> >
> >
> > Based on those feedback, we decided to use pattern-driven in ICU. But
> > provide algorithm for CLDR survey tool.
> >
> >
> >
> > 4. Logically, the patterns are mappings from (skeleton,
> > the_largest_different_calendar_field) to (date_interval_pattern).
> >
> > For example, for a skeleton "dMMMy" in en_US, if the largest different
> > calendar field between date1 and date2 is "year", the date interval pattern
> > is "MMM d, yyyy - MMM d, yyyy", such as "Jan 10, 2007 - Jan 10, 2008".
> >
> > If the largest different calendar field between date1 and date2 is
> > "month", the date interval pattern is "MMM d - MMM d, yyyy", such as "Jan 10
> > - Feb 10, 2007".
> >
> > If the largest different calendar field between date1 and date2 is
> > "day", the date interval pattern is ""MMM d-d, yyyy", such as "Jan 10-20,
> > 2007".
> >
> > For a skeleton "MMMy", if the largest different calendar field between
> > date1 and date2 is "month". the interval pattern is "MMM-MMM, yyyy", such as
> > "Jan-Feb, 2007".
> > Since we are implementing interval date/time format using
> > pattern-driven, then we will need to add interval patterns into resource
> > files.
> > To represent above information, we will introduce another class:
> > DateIntervalInfo.
> >
> > It is either constructed given a Locale, or constructed by user-supplied
> > list.
> >
> >
> > 5. DateIntervalFormat will need the following information for correct
> > formatting: time zone, calendar type, pattern, date format symbols, and
> > DateIntervalInfo.
> >
> > It will be constructed by the following 2 createInstance() member
> > functions:
> >
> >
> > createInstance(const DateFormat*, const Locale&)
> > and
> > createInstance(const DateFormat*, const DateIntervalInfo* )
> >
> > DateFormat object provides time zone, calendar type, pattern, and date
> > format symbols information for DateIntervalFormat.
> > Locale object provides the default date/time interval patterns. Or users
> > can replace the default interval patterns with their own patterns in
> > DateIntervalInfo object
> >
> > Both of the above 2 functions will call a protected constructor
> > DateIntervalFormat(DateFormat &, const DateIntervalInfo & ) to construct
> > the DateIntervalFormat object.
> >
> >
> > Please be noted, the DateFormat object needs to be a SimpleDateFormat
> > object which has a pattern in it.
> >
> > Also please be noted, if caller constructed SimpleDateFormat object by
> > providing a pattern, all the other information except the real pattern (
> > such as 'y', 'M', 'd', 'E', 'H', 'h', 'm' etc.) are thrown away when
> > convert the full pattern into skeleton.
> >
> > For example, for English, if caller creates SimpleDateFormat object
> > using pattern "dd 'of' MMM 'in' yyyy", "of" and "in" will be thrown away,
> > and the converted skeleton is "ddMMMyyyy".
> > If day is different, the interval result will be "Jan 10-20, 2008", and
> > it won't be "10-20 of Jan in 2008".
> >
> >
> >
> >
> >
> > Following is a code sample of the usage:
> >
> > /* the date interval object which the DateIntervalFormat formats on
> > * and parses into
> > */
> > DateInterval* dtInterval = new DateInterval(1000*3600*24,
> > 1000*3600*24*2);
> >
> > DateFormat* dtFmt = DateFormat::createDateInstance(DateFormat::FULL,
> > Locale("en", "GB", ""));
> >
> > DateIntervalFormat* dtIntervalFmt =
> > DateIntervalFormat::createInstance(dtFmt, Locale("en", "GB", ""));
> >
> > UnicodeString dateIntervalString;
> > UErrorCode status = U_ZERO_ERROR;
> >
> > /* formatting */
> >
> > dtIntervalFmt->format(dtInterval, dateIntervalString, status);
> >
> >
> >
> > Thanks,
> > Xiaomei
> >
> > -------------------------------------------------------------------------
> >
> > 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
>
|
|
From: xiaomei j. <xia...@gm...> - 2008-01-21 19:29:37
Attachments:
dtitvinf.h
|
LyoKKiBDb3B5cmlnaHQgKEMpIDIwMDgsIEludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMg Q29ycG9yYXRpb24gYW5kIG90aGVycy4gQWxsIFJpZ2h0cyBSZXNlcnZlZC4KKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKgoqCiogRmlsZSBEVElUVkZNVC5ICioKKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgoq LwoKI2lmbmRlZiBEVElUVkZNVF9IX18KI2RlZmluZSBEVElUVkZNVF9IX18KCgovKioKICogXGZp bGUgCiAqIFxicmllZiBDKysgQVBJOiBGb3JtYXQgYW5kIHBhcnNlIGRhdGUgaW50ZXJ2YWwgaW4g YSBsYW5ndWFnZS1pbmRlcGVuZGVudCBtYW5uZXIuCiAqLwogCiNpZiAhVUNPTkZJR19OT19GT1JN QVRUSU5HCgojaW5jbHVkZSAidW5pY29kZS91dHlwZXMuaCIKI2luY2x1ZGUgInVuaWNvZGUvZm9y bWF0LmgiCiNpbmNsdWRlICJ1bmljb2RlL3NtcGR0Zm10LmgiCiNpbmNsdWRlICJ1bmljb2RlL2R0 aXR2aW5mLmgiCgpVX05BTUVTUEFDRV9CRUdJTgoKY2xhc3MgRGF0ZUludGVydmFsRm9ybWF0Owpj bGFzcyBNZXNzYWdlRm9ybWF0OwoKLyoqCiAqCiAqIDxjb2RlPkRhdGVJbnRlcnZhbEZvcm1hdDwv Y29kZT4gaXMgYSBjbGFzcyBmb3IgZm9ybWF0dGluZyBhbmQgcGFyc2luZyBkYXRlIAogKiBpbnRl cnZhbHMgaW4gYSBsYW5ndWFnZS1pbmRlcGVuZGVudCBtYW5uZXIuIAogKiA8UD4KICogRGF0ZSBp bnRlcnZhbCBtZWFucyBmcm9tIG9uZSBkYXRlIHRvIGFub3RoZXIgZGF0ZSwKICogZm9yIGV4YW1w bGUsIGZyb20gIkphbiAxMSwgMjAwOCIgdG8gIkphbiAxOCwgMjAwOCIuCiAqIFdlIGludHJvZHVj ZWQgY2xhc3MgPGNvZGU+RGF0ZUludGVydmFsPC9jb2RlPiB0byByZXByZXNlbnQgaXQuCiAqIDxj b2RlPkRhdGVJbnRlcnZhbDwvY29kZT4gaXMgYSBwYWlyIG9mIDxjb2RlPlVEYXRlPC9jb2RlPiwg d2hpY2ggaXMgCiAqIHRoZSBzdGFuZGFyZCBtaWxsaXNlY29uZHMgc2luY2UgMjQ6MDAgR01ULCBK YW4gMSwgMTk3MC4KICogPFA+CiAqIDxjb2RlPkRhdGVJbnRlcnZhbEZvcm1hdDwvY29kZT4gZm9y bWF0cyBhIDxjb2RlPkRhdGVJbnRlcnZhbDwvY29kZT4gaW50bwogKiB0ZXh0LiBBbmQgaXQgcGFy c2VzIHRleHQgaW50byA8Y29kZT5EYXRlSW50ZXJ2YWw8L2NvZGU+LCAKICogYWx0aG91Z2ggaW5p dGlhbGx5LCBwYXJzaW5nIGlzIG5vdCBzdXBwb3J0ZWQuIAogKiA8UD4KICogRm9ybWF0dGluZyBh IDxjb2RlPkRhdGVJbnRlcnZhbDwvY29kZT4gaXMgcGF0dGVybi1kcml2ZW4uIEl0IGlzIHZlcnkK ICogc2ltaWxhciB0byBmb3JtYXR0aW5nIGluIDxjb2RlPkRhdGVJbnRlcnZhbEZvcm1hdDwvY29k ZT4uCiAqIFdlIGludHJvZHVjZSBjbGFzcyA8Y29kZT5EYXRlSW50ZXJ2YWxJbmZvPC9jb2RlPiB0 byBzYXZlIGRhdGUgaW50ZXJ2YWwgCiAqIHBhdHRlcm5zLCBzaW1pbGFyIHRvIGRhdGUgdGltZSBw YXR0ZXJuIGluIDxjb2RlPkRhdGVJbnRlcnZhbEZvcm1hdDwvY29kZT4uCiAqIDxQPgogKiA8Y29k ZT5EYXRlSW50ZXJ2YWxGb3JtYXQ8L2NvZGU+IG5lZWRzIHRoZSBmb2xsb3dpbmcgaW5mb3JtYXRp b24gZm9yIGNvcnJlY3QgCiAqIGZvcm1hdHRpbmc6IHRpbWUgem9uZSwgY2FsZW5kYXIgdHlwZSwg cGF0dGVybiwgZGF0ZSBmb3JtYXQgc3ltYm9scywgCiAqIGFuZCBEYXRlSW50ZXJ2YWxJbmZvLiAK ICogPFA+CiAqIENsaWVudHMgYXJlIGVuY291cmFnZWQgdG8gY3JlYXRlIGEgZGF0ZS10aW1lIGlu dGVydmFsIGZvcm1hdHRlciB1c2luZyAKICogPHByZT4KICogRGF0ZUludGVydmFsRm9ybWF0Ojpn ZXRJbnN0YW5jZShjb25zdCBEYXRlRm9ybWF0KiwgY29uc3QgTG9jYWxlJikuCiAqIDwvcHJlPgog KiBBbmQgcGxlYXNlIGJlIG5vdGVkIHRoYXQgdGhlIDFzdCBwYXJhbWV0ZXIgbmVlZHMgdG8gYmUg YSBEYXRlSW50ZXJ2YWxGb3JtYXQsCiAqIHdoaWNoIGhhcyBhIHBhdHRlcm4gaW4gaXQuCiAqIDxQ PgogKiBBbHNvIHBsZWFzZSBiZSBub3RlZCwgaWYgY2FsbGVyIGNvbnN0cnVjdGVkIERhdGVJbnRl cnZhbEZvcm1hdCBvYmplY3QgYnkgCiAqIHByb3ZpZGluZyBhIHBhdHRlcm4sIGFsbCB0aGUgb3Ro ZXIgaW5mb3JtYXRpb24gZXhjZXB0IHRoZSByZXNlcnZlZCBBU0NJSSAKICogcGF0dGVybiBsZXR0 ZXJzICggc3VjaCBhcyAneScsICdNJywgJ2QnLCAnRScsICdIJywgJ2gnLCAnbScgZXRjLikgYXJl IAogKiB0aHJvd24gYXdheSBmcm9tIHRoZSBmdWxsIHBhdHRlcm4uCiAqIDxQPgogKiBGb3IgZXhh bXBsZSwgZm9yIEVuZ2xpc2gsIGlmIGNhbGxlciBjcmVhdGVzIERhdGVJbnRlcnZhbEZvcm1hdCBv YmplY3QgdXNpbmcgCiAqIHBhdHRlcm4gImRkICdvZicgTU1NICdpbicgeXl5eSIsICAib2YiIGFu ZCAiaW4iIHdpbGwgYmUgdGhyb3duIGF3YXksIAogKiBhbmQgdGhlIGNvbnZlcnRlZCBza2VsZXRv biBpcyAiZGRNTU15eXl5Ii4KICogSWYgZGF5IGlzIGRpZmZlcmVudCwgdGhlIGludGVydmFsIHJl c3VsdCB3aWxsIGJlICJKYW4gMTAtMjAsIDIwMDgiLCAKICogYW5kIGl0IHdvbid0IGJlICIxMC0y MCBvZiAgSmFuIGluIDIwMDgiLgogKgogKiA8UD4KICogPGNvZGU+RGF0ZUZvcm1hdDwvY29kZT4g KGFjdHVhbGx5IDxjb2RlPkRhdGVJbnRlcnZhbEZvcm1hdDwvY29kZT4pIHByb3ZpZGVzCiAqIHRp bWV6b25lLCBjYWxlbmRhciB0eXBlLCBwYXR0ZXJuLCBhbmQgZGF0ZSBmb3JtYXQgc3ltYm9scyBp bmZvcm1hdGlvbi4KICogPGNvZGU+TG9jYWxlPC9jb2RlPiBwcm92aWRlcyB0aGUgZGF0ZS90aW1l IGludGVydmFsIHBhdHRlcm5zLgogKiA8UD4KICogSWYgY2xpZW50cyBkZWNpZGVkIHRvIGNyZWF0 ZSA8Y29kZT5EYXRlSW50ZXJ2YWxGb3JtYXQ8L2NvZGU+IG9iamVjdCAKICogYnkgc3VwcGx5aW5n IHRoZWlyIG93biBpbnRlcnZhbCBwYXR0ZXJucywgdGhleSBjYW4gZG8gc28gd2l0aCAKICogPHBy ZT4KICogRGF0ZUludGVydmFsRm9ybWF0OjpnZXRJbnN0YW5jZShjb25zdCBEYXRlRm9ybWF0Kiwg Y29uc3QgRGF0ZUludGVydmFsSW5mbyopLgogKiA8L3ByZT4KICogSGVyZSwgPGNvZGU+RGF0ZUlu dGVydmFsRm9ybWF0PC9jb2RlPiBvYmplY3QgaXMgaW5pdGlhbGl6ZWQgd2l0aCB0aGUgaW50ZXJ2 YWwgKiBwYXR0ZXJucyBjbGllbnQgc3VwcGxpZWQuIEl0IHByb3ZpZGVzIGZsZXhpYmlsaXR5IGZv ciBwb3dlcmZ1bCB1c2FnZS4KICoKICogPFA+CiAqIDxjb2RlPkRhdGVJbnRlcnZhbEZvcm1hdDwv Y29kZT4gdXNlcyB0aGUgc2FtZSBzeW50YXggYXMgdGhhdCBvZgogKiBEYXRlL1RpbWUgZm9ybWF0 LgogKiAKICogPFA+CiAqIENvZGUgU2FtcGxlOgogKiA8cHJlPgogKiBcY29kZQogKiAgIC8vIHRo ZSBkYXRlIGludGVydmFsIG9iamVjdCB3aGljaCB0aGUgRGF0ZUludGVydmFsRm9ybWF0IGZvcm1h dHMgb24KICogICAvLyBhbmQgcGFyc2VzIGludG8KICogICBEYXRlSW50ZXJ2YWwqICBkdEludGVy dmFsID0gbmV3IERhdGVJbnRlcnZhbCgxMDAwKjM2MDAqMjQsIDEwMDAqMzYwMCoyNCoyKTsKICog ICBEYXRlRm9ybWF0KiBkdEZtdCA9IERhdGVGb3JtYXQ6OmNyZWF0ZURhdGVJbnN0YW5jZSgKICog ICAgICAgICAgICAgICAgICAgICAgICAgICBEYXRlRm9ybWF0OjpGVUxMLCBMb2NhbGUoImVuIiwg IkdCIiwgIiIpKTsKICogICBEYXRlSW50ZXJ2YWxGb3JtYXQqIGR0SW50ZXJ2YWxGbXQgPSBEYXRl SW50ZXJ2YWxGb3JtYXQ6OmNyZWF0ZUluc3RhbmNlKAogKiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBkdEZtdCwgTG9jYWxlKCJlbiIsICJHQiIsICIiKSk7CiAqICAg VW5pY29kZVN0cmluZyBkYXRlSW50ZXJ2YWxTdHJpbmc7CiAqICAgVUVycm9yQ29kZSBzdGF0dXMg PSBVX1pFUk9fRVJST1I7CiAqICAgLy8gZm9ybWF0dGluZwogKiAgIGR0SW50ZXJ2YWxGbXQtPmZv cm1hdChkdEludGVydmFsLCBkYXRlSW50ZXJ2YWxTdHJpbmcsIHN0YXR1cyk7CiAqIFxlbmRjb2Rl CiAqIDwvcHJlPgogKiA8Y29kZT5Mb2NhbGU8L2NvZGU+IHBhc3NlZCB0byBEYXRlRm9ybWF0IGRl dGVybWluZXMgdGhlIHRpbWV6b25lLAogKiBjYWxlbmRhciwgcGF0dGVybiwgYW5kIGRhdGUgZm9y bWF0IHN5bWJvbHMuCiAqIDxjb2RlPkxvY2FsZTwvY29kZT4gcGFzc2VkIHRvIDxjb2RlPkRhdGVJ bnRlcnZhbEZvcm1hdDwvY29kZT4gZGV0ZXJtaW5lcwogKiB0aGUgZGF0ZSBpbnRlcnZhbCBwYXR0 ZXJucy4KICogSWYgY2xpZW50IHBhc3NlcyAyIGRpZmZlcmVudCBsb2NhbGVzIHRvIGNyZWF0ZSA8 Y29kZT5EYXRlRm9ybWF0PC9jb2RlPgogKiBhbmQgPGNvZGU+RGF0ZUludGVydmFsRm9ybWF0PC9j b2RlPiwgdGhlcmUgbWlnaHQgYmUgaW4tY29uc2lzdGVuY3kgaW52b2x2ZWQuCiAqLwoKY2xhc3Mg VV9JMThOX0FQSSBEYXRlSW50ZXJ2YWxGb3JtYXQgOiBwdWJsaWMgRm9ybWF0IHsKcHVibGljOgoK ICAgIC8qKgogICAgICogQ29uc3RydWN0IGEgRGF0ZUludGVydmFsRm9ybWF0IGZyb20gZGVmYXVs dCBsb2NhbGUuIAogICAgICogSXQgdXNlcyB0aGUgaW50ZXJ2YWwgcGF0dGVybnMgb2YgZGVmYXVs dCBza2VsZXRvbiAoImRNTU15aG0iKSAKICAgICAqIGZyb20gdGhlIGRlZmF1bHQgbG9jYWxlLgog ICAgICogQHBhcmFtIHN0YXR1cyAgICBPdXRwdXQgcGFyYW0gc2V0IHRvIHN1Y2Nlc3MvZmFpbHVy ZSBjb2RlLgogICAgICogQGRyYWZ0IElDVSAzLjkKICAgICAqLwogICAgc3RhdGljIERhdGVJbnRl cnZhbEZvcm1hdCogY3JlYXRlSW5zdGFuY2UoVUVycm9yQ29kZSYgc3RhdHVzKTsKCiAgICAvKioK ICAgICAqIENvbnN0cnVjdCBhIERhdGVJbnRlcnZhbEZvcm1hdCB1c2luZyBnaXZlbiBsb2NhbGUu CiAgICAgKiBJdCB1c2VzIHRoZSBpbnRlcnZhbCBwYXR0ZXJucyBvZiBkZWZhdWx0IHNrZWxldG9u ICgiZE1NTXlobSIpIAogICAgICogZnJvbSB0aGUgZ2l2ZW4gbG9jYWxlLgogICAgICogQHBhcmFt IGxvY2FsZSAgICB0aGUgZ2l2ZW4gbG9jYWxlLgogICAgICogQHBhcmFtIHN0YXR1cyAgICBPdXRw dXQgcGFyYW0gc2V0IHRvIHN1Y2Nlc3MvZmFpbHVyZSBjb2RlLgogICAgICogQGRyYWZ0IElDVSAz LjkKICAgICAqLwogICAgc3RhdGljIERhdGVJbnRlcnZhbEZvcm1hdCogY3JlYXRlSW5zdGFuY2Uo Y29uc3QgTG9jYWxlJiBsb2NhbGUsIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgVUVycm9yQ29kZSYgc3RhdHVzKTsKCiAgICAvKioKICAgICAqIENvbnN0cnVj dCBhIERhdGVJbnRlcnZhbEZvcm1hdCBmcm9tIDxjb2RlPkRhdGVGb3JtYXQ8L2NvZGU+CiAgICAg KiBhbmQgYSBnaXZlbiBsb2NhbGUuCiAgICAgKiA8Y29kZT5EYXRlRm9ybWF0PC9jb2RlPiBwcm92 aWRlcyB0aGUgdGltZXpvbmUsIGNhbGVuZGFyLAogICAgICogZnVsbCBwYXR0ZXJuLCBhbmQgZGF0 ZSBmb3JtYXQgc3ltYm9scyBpbmZvcm1hdGlvbi4KICAgICAqIEl0IHNob3VsZCBiZSBhIDxjb2Rl PlNpbXBsZURhdGVGb3JtYXQ8L2NvZGU+IG9iamVjdCB3aGljaCAKICAgICAqIGhhcyBhIHBhdHRl cm4gaW4gaXQuCiAgICAgKiBUaGUgZ2l2ZW4gPGNvZGU+TG9jYWxlPC9jb2RlPiBwcm92aWRlcyB0 aGUgaW50ZXJ2YWwgcGF0dGVybnMuCiAgICAgKiBBIHNrZWxldG9uIGlzIGRlcml2ZWQgZnJvbSB0 aGUgZnVsbCBwYXR0ZXJuLiAKICAgICAqIEFuZCB0aGUgaW50ZXJ2YWwgcGF0dGVybnMgYXJlIHRo b3NlIHRoZSBza2VsZXRvbiBtYXBzIHRvCiAgICAgKiBpbiB0aGUgZ2l2ZW4gbG9jYWxlLgogICAg ICogRm9yIGV4YW1wbGUsIGZvciBlbl9HQiwgaWYgdGhlIHBhdHRlcm4gaW4gdGhlIDxjb2RlPlNp bXBsZURhdGVGb3JtYXQ8L2NvZGU+CiAgICAgKiBpcyAiRUVFLCBkIE1NTSwgeXl5eSIsIHRoZSBz a2VsZXRvbiBpcyAiRUVFZE1NTXl5eSIuCiAgICAgKiBBbmQgdGhlIGludGVydmFsIHBhdHRlcm5z IGFyZToKICAgICAqICJFRUUsIGQgTU1NLCB5eXl5IC0gRUVFLCBkIE1NTSwgeXl5eSIgZm9yIHll YXIgZGlmZmVycywKICAgICAqICJFRUUsIGQgTU1NIC0gRUVFLCBkIE1NTSwgeXl5eSIgZm9yIG1v bnRoIGRpZmZlcnMsCiAgICAgKiAiRUVFLCBkIC0gRUVFLCBkIE1NTSwgeXl5eSIgZm9yIGRheSBk aWZmZXJzLAogICAgICogQHBhcmFtIGR0Zm10ICAgICB0aGUgPGNvZGU+RGF0ZUZvcm1hdDwvY29k ZT4gb2JqZWN0CiAgICAgKiBAcGFyYW0gbG9jYWxlICAgIHRoZSBnaXZlbiBsb2NhbGUuCiAgICAg KiBAcGFyYW0gc3RhdHVzICAgIE91dHB1dCBwYXJhbSBzZXQgdG8gc3VjY2Vzcy9mYWlsdXJlIGNv ZGUuCiAgICAgKiBAZHJhZnQgSUNVIDMuOQogICAgICovCiAgICBzdGF0aWMgRGF0ZUludGVydmFs Rm9ybWF0KiBjcmVhdGVJbnN0YW5jZShjb25zdCBEYXRlRm9ybWF0KiBkdGZtdCwgCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCBMb2NhbGUmIGxvY2Fs ZSwgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBVRXJyb3JD b2RlJiBzdGF0dXMpOwoKICAgIC8qKgogICAgICogQ29uc3RydWN0IGEgRGF0ZUludGVydmFsRm9y bWF0IGZyb20gPGNvZGU+RGF0ZUZvcm1hdDwvY29kZT4KICAgICAqIGFuZCBhIDxjb2RlPkRhdGVJ bnRlcnZhbEluZm88L2NvZGU+LgogICAgICogPGNvZGU+RGF0ZUZvcm1hdDwvY29kZT4gcHJvdmlk ZXMgdGhlIHRpbWV6b25lLCBjYWxlbmRhciwKICAgICAqIGZ1bGwgcGF0dGVybiwgYW5kIGRhdGUg Zm9ybWF0IHN5bWJvbHMgaW5mb3JtYXRpb24uCiAgICAgKiBJdCBzaG91bGQgYmUgYSA8Y29kZT5T aW1wbGVEYXRlRm9ybWF0PC9jb2RlPiBvYmplY3Qgd2hpY2ggCiAgICAgKiBoYXMgYSBwYXR0ZXJu IGluIGl0LgogICAgICogdGhlIDxjb2RlPkRhdGVJbnRlcnZhbEluZm88L2NvZGU+IHByb3ZpZGVz IHRoZSBpbnRlcnZhbCBwYXR0ZXJucy4KICAgICAqIEBwYXJhbSBsb2NhbGUgICAgdGhlIGdpdmVu IGxvY2FsZS4KICAgICAqIEBwYXJhbSBzdGF0dXMgICAgT3V0cHV0IHBhcmFtIHNldCB0byBzdWNj ZXNzL2ZhaWx1cmUgY29kZS4KICAgICAqIEBkcmFmdCBJQ1UgMy45CiAgICAgKi8KICAgIHN0YXRp YyBEYXRlSW50ZXJ2YWxGb3JtYXQqIGNyZWF0ZUluc3RhbmNlKGNvbnN0IERhdGVGb3JtYXQqIGR0 Zm10LCAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0 IERhdGVJbnRlcnZhbEluZm8qIGR0aXR2aW5mLAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgVUVycm9yQ29kZSYgc3RhdHVzKTsKCiAgICAvKioKICAgICAqIENv cHkgY29uc3RydWN0b3IuCiAgICAgKiBAZHJhZnQgSUNVIDMuOQogICAgICovCiAgICBEYXRlSW50 ZXJ2YWxGb3JtYXQoY29uc3QgU2ltcGxlRGF0ZUZvcm1hdCYpOwoKICAgIC8qKgogICAgICogQXNz aWdubWVudCBvcGVyYXRvci4KICAgICAqIEBkcmFmdCBJQ1UgMy45CiAgICAgKi8KICAgIERhdGVJ bnRlcnZhbEZvcm1hdCYgb3BlcmF0b3I9KGNvbnN0IFNpbXBsZURhdGVGb3JtYXQmKTsKCiAgICAv KioKICAgICAqIERlc3RydWN0b3IuCiAgICAgKiBAZHJhZnQgSUNVIDMuOQogICAgICovCiAgICB2 aXJ0dWFsIH5EYXRlSW50ZXJ2YWxGb3JtYXQoKTsKCiAgICAvKioKICAgICAqIENsb25lIHRoaXMg Rm9ybWF0IG9iamVjdCBwb2x5bW9ycGhpY2FsbHkuIFRoZSBjYWxsZXIgb3ducyB0aGUgcmVzdWx0 IGFuZAogICAgICogc2hvdWxkIGRlbGV0ZSBpdCB3aGVuIGRvbmUuCiAgICAgKiBAcmV0dXJuICAg IEEgY29weSBvZiB0aGUgb2JqZWN0LgogICAgICogQGRyYWZ0IElDVSAzLjkKICAgICAqLwogICAg dmlydHVhbCBGb3JtYXQqIGNsb25lKHZvaWQpIGNvbnN0OwoKICAgIC8qKgogICAgICogUmV0dXJu IHRydWUgaWYgdGhlIGdpdmVuIEZvcm1hdCBvYmplY3RzIGFyZSBzZW1hbnRpY2FsbHkgZXF1YWwu IE9iamVjdHMKICAgICAqIG9mIGRpZmZlcmVudCBzdWJjbGFzc2VzIGFyZSBjb25zaWRlcmVkIHVu ZXF1YWwuCiAgICAgKiBAcGFyYW0gb3RoZXIgICAgdGhlIG9iamVjdCB0byBiZSBjb21wYXJlZCB3 aXRoLgogICAgICogQHJldHVybiAgICAgICAgIHRydWUgaWYgdGhlIGdpdmVuIEZvcm1hdCBvYmpl Y3RzIGFyZSBzZW1hbnRpY2FsbHkgZXF1YWwuCiAgICAgKiBAZHJhZnQgSUNVIDMuOQogICAgICov CiAgICB2aXJ0dWFsIFVCb29sIG9wZXJhdG9yPT0oY29uc3QgRm9ybWF0JiBvdGhlcikgY29uc3Q7 CgogICAgLyoqCiAgICAgKiBSZXR1cm4gdHJ1ZSBpZiB0aGUgZ2l2ZW4gRm9ybWF0IG9iamVjdHMg YXJlIG5vdCBzZW1hbnRpY2FsbHkgZXF1YWwuIAogICAgICogT2JqZWN0cyBvZiBkaWZmZXJlbnQg c3ViY2xhc3NlcyBhcmUgY29uc2lkZXJlZCB1bmVxdWFsLgogICAgICogQHBhcmFtIG90aGVyIHRo ZSBvYmplY3QgdG8gYmUgY29tcGFyZWQgd2l0aC4KICAgICAqIEByZXR1cm4gICAgICB0cnVlIGlm IHRoZSBnaXZlbiBGb3JtYXQgb2JqZWN0cyBhcmUgbm90IHNlbWFudGljYWxseSBlcXVhbC4KICAg ICAqIEBkcmFmdCBJQ1UgMy45CiAgICAgKi8KICAgIHZpcnR1YWwgVUJvb2wgb3BlcmF0b3IhPShj b25zdCBGb3JtYXQmIG90aGVyKSBjb25zdCB7IHJldHVybiAhb3BlcmF0b3I9PShvdGhlcik7IH0K CiAgICAvKioKICAgICAqIEZvcm1hdCBhbiBvYmplY3QgdG8gcHJvZHVjZSBhIHN0cmluZy4gVGhp cyBtZXRob2QgaGFuZGxlcyBGb3JtYXR0YWJsZQogICAgICogb2JqZWN0cyB3aXRoIGEgPGNvZGU+ RGF0ZUludGVydmFsPC9jb2RlPiB0eXBlLiAKICAgICAqIElmIGEgdGhlIEZvcm1hdHRhYmxlIG9i amVjdCB0eXBlIGlzIG5vdCBhIDxjb2RlPkRhdGVJbnRlcnZhbDwvY29kZT4sCiAgICAgKiB0aGVu IGl0IHJldHVybnMgYSBmYWlsaW5nIFVFcnJvckNvZGUuCiAgICAgKgogICAgICogQHBhcmFtIG9i aiAgICAgICAgICAgICAgIFRoZSBvYmplY3QgdG8gZm9ybWF0LiAKICAgICAqICAgICAgICAgICAg ICAgICAgICAgICAgICBNdXN0IGJlIGEgPGNvZGU+RGF0ZUludGVydmFsPC9jb2RlPi4KICAgICAq IEBwYXJhbSBhcHBlbmRUbyAgICAgICAgICBPdXRwdXQgcGFyYW1ldGVyIHRvIHJlY2VpdmUgcmVz dWx0LgogICAgICogICAgICAgICAgICAgICAgICAgICAgICAgIFJlc3VsdCBpcyBhcHBlbmRlZCB0 byBleGlzdGluZyBjb250ZW50cy4KICAgICAqIEBwYXJhbSBmaWVsZFBvc2l0aW9uICAgICBPbiBp bnB1dDogYW4gYWxpZ25tZW50IGZpZWxkLCBpZiBkZXNpcmVkLgogICAgICogICAgICAgICAgICAg ICAgICAgICAgICAgIE9uIG91dHB1dDogdGhlIG9mZnNldHMgb2YgdGhlIGFsaWdubWVudCBmaWVs ZC4KICAgICAqIEBwYXJhbSBzdGF0dXMgICAgICAgICAgICBPdXRwdXQgcGFyYW0gZmlsbGVkIHdp dGggc3VjY2Vzcy9mYWlsdXJlIHN0YXR1cy4KICAgICAqIEByZXR1cm4gICAgICAgICAgICAgICAg ICBSZWZlcmVuY2UgdG8gJ2FwcGVuZFRvJyBwYXJhbWV0ZXIuCiAgICAgKiBAZHJhZnQgSUNVIDMu OQogICAgICovCiAgICB2aXJ0dWFsIFVuaWNvZGVTdHJpbmcmIGZvcm1hdChjb25zdCBGb3JtYXR0 YWJsZSYgb2JqLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVW5pY29kZVN0cmlu ZyYgYXBwZW5kVG8sCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWVsZFBvc2l0 aW9uJiBmaWVsZFBvc2l0aW9uLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVUVy cm9yQ29kZSYgc3RhdHVzKSBjb25zdCA7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKCiAgICAvKioKICAgICAq IEZvcm1hdCBhIDxjb2RlPkRhdGVJbnRlcnZhbDwvY29kZT4gdG8gcHJvZHVjZSBhIHN0cmluZy4g CiAgICAgKgogICAgICogQHBhcmFtIGR0SW50ZXJ2YWwgICAgICAgICAgPGNvZGU+RGF0ZUludGVy dmFsPC9jb2RlPiB0byBiZSBmb3JtYXR0ZWQuCiAgICAgKiBAcGFyYW0gYXBwZW5kVG8gICAgICAg ICAgICBPdXRwdXQgcGFyYW1ldGVyIHRvIHJlY2VpdmUgcmVzdWx0LgogICAgICogICAgICAgICAg ICAgICAgICAgICAgICAgICAgUmVzdWx0IGlzIGFwcGVuZGVkIHRvIGV4aXN0aW5nIGNvbnRlbnRz LgogICAgICogQHBhcmFtIGZpZWxkUG9zaXRpb24gICAgICAgT24gaW5wdXQ6IGFuIGFsaWdubWVu dCBmaWVsZCwgaWYgZGVzaXJlZC4KICAgICAqICAgICAgICAgICAgICAgICAgICAgICAgICAgIE9u IG91dHB1dDogdGhlIG9mZnNldHMgb2YgdGhlIGFsaWdubWVudCBmaWVsZC4KICAgICAqIEByZXR1 cm4gICAgICAgICAgICAgICAgICAgIFJlZmVyZW5jZSB0byAnYXBwZW5kVG8nIHBhcmFtZXRlci4K ICAgICAqIEBkcmFmdCBJQ1UgMy45CiAgICAgKi8KICAgIFVuaWNvZGVTdHJpbmcmIGZvcm1hdChj b25zdCBEYXRlSW50ZXJ2YWwmIGR0SW50ZXJ2YWwsCiAgICAgICAgICAgICAgICAgICAgICAgICAg VW5pY29kZVN0cmluZyYgYXBwZW5kVG8sCiAgICAgICAgICAgICAgICAgICAgICAgICAgRmllbGRQ b3NpdGlvbiYgZmllbGRQb3NpdGlvbikgY29uc3QgOwogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAvKioK ICAgICAqIFBhcnNlIGEgc3RyaW5nIHRvIHByb2R1Y2UgYW4gb2JqZWN0LiBUaGlzIG1ldGhvZHMg aGFuZGxlcyBwYXJzaW5nIG9mCiAgICAgKiBkYXRlIHRpbWUgaW50ZXJ2YWwgc3RyaW5ncyBpbnRv IEZvcm1hdHRhYmxlIG9iamVjdHMgd2l0aCAKICAgICAqIDxjb2RlPkRhdGVJbnRlcnZhbDwvY29k ZT4gdHlwZSwgd2hpY2ggaXMgYSBwYWlyIG9mIFVEYXRlLgogICAgICogPFA+CiAgICAgKiBJbiBJ Q1UgMy45LCBkYXRlIGludGVydmFsIGZvcm1hdCBpcyBub3Qgc3VwcG9ydGVkLgogICAgICogPFA+ CiAgICAgKiBCZWZvcmUgY2FsbGluZywgc2V0IHBhcnNlX3Bvcy5pbmRleCB0byB0aGUgb2Zmc2V0 IHlvdSB3YW50IHRvIHN0YXJ0CiAgICAgKiBwYXJzaW5nIGF0IGluIHRoZSBzb3VyY2UuIEFmdGVy IGNhbGxpbmcsIHBhcnNlX3Bvcy5pbmRleCBpcyB0aGUgZW5kIG9mCiAgICAgKiB0aGUgdGV4dCB5 b3UgcGFyc2VkLiBJZiBlcnJvciBvY2N1cnMsIGluZGV4IGlzIHVuY2hhbmdlZC4KICAgICAqIDxQ PgogICAgICogV2hlbiBwYXJzaW5nLCBsZWFkaW5nIHdoaXRlc3BhY2UgaXMgZGlzY2FyZGVkICh3 aXRoIGEgc3VjY2Vzc2Z1bCBwYXJzZSksCiAgICAgKiB3aGlsZSB0cmFpbGluZyB3aGl0ZXNwYWNl IGlzIGxlZnQgYXMgaXMuCiAgICAgKiA8UD4KICAgICAqIFNlZSBGb3JtYXQ6OnBhcnNlT2JqZWN0 KCkgZm9yIG1vcmUuCiAgICAgKgogICAgICogQHBhcmFtIHNvdXJjZSAgICBUaGUgc3RyaW5nIHRv IGJlIHBhcnNlZCBpbnRvIGFuIG9iamVjdC4KICAgICAqIEBwYXJhbSByZXN1bHQgICAgRm9ybWF0 dGFibGUgdG8gYmUgc2V0IHRvIHRoZSBwYXJzZSByZXN1bHQuCiAgICAgKiAgICAgICAgICAgICAg ICAgIElmIHBhcnNlIGZhaWxzLCByZXR1cm4gY29udGVudHMgYXJlIHVuZGVmaW5lZC4KICAgICAq IEBwYXJhbSBwYXJzZV9wb3MgVGhlIHBvc2l0aW9uIHRvIHN0YXJ0IHBhcnNpbmcgYXQuIFVwb24g cmV0dXJuCiAgICAgKiAgICAgICAgICAgICAgICAgIHRoaXMgcGFyYW0gaXMgc2V0IHRvIHRoZSBw b3NpdGlvbiBhZnRlciB0aGUKICAgICAqICAgICAgICAgICAgICAgICAgbGFzdCBjaGFyYWN0ZXIg c3VjY2Vzc2Z1bGx5IHBhcnNlZC4gSWYgdGhlCiAgICAgKiAgICAgICAgICAgICAgICAgIHNvdXJj ZSBpcyBub3QgcGFyc2VkIHN1Y2Nlc3NmdWxseSwgdGhpcyBwYXJhbQogICAgICogICAgICAgICAg ICAgICAgICB3aWxsIHJlbWFpbiB1bmNoYW5nZWQuCiAgICAgKiBAcmV0dXJuICAgICAgICAgIEEg bmV3bHkgY3JlYXRlZCBGb3JtYXR0YWJsZSogb2JqZWN0LCBvciBOVUxMCiAgICAgKiAgICAgICAg ICAgICAgICAgIG9uIGZhaWx1cmUuICBUaGUgY2FsbGVyIG93bnMgdGhpcyBhbmQgc2hvdWxkCiAg ICAgKiAgICAgICAgICAgICAgICAgIGRlbGV0ZSBpdCB3aGVuIGRvbmUuCiAgICAgKiBAZHJhZnQg SUNVIDMuOQogICAgICovCiAgICB2aXJ0dWFsIHZvaWQgcGFyc2VPYmplY3QoY29uc3QgVW5pY29k ZVN0cmluZyYgc291cmNlLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZvcm1hdHRhYmxl JiByZXN1bHQsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUGFyc2VQb3NpdGlvbiYgcGFy c2VfcG9zKSBjb25zdDsKCgogICAgLyoqCiAgICAgKiBHZXRzIHRoZSBkYXRlIHRpbWUgaW50ZXJ2 YWwgcGF0dGVybnMuCiAgICAgKiBAcmV0dXJuIGEgY29weSBvZiB0aGUgZGF0ZSB0aW1lIGludGVy dmFsIHBhdHRlcm5zIGFzc29jaWF0ZWQgd2l0aAogICAgICogdGhpcyBkYXRlIGludGVydmFsIGZv cm1hdHRlci4KICAgICAqIEBkcmFmdCBJQ1UgMy45CiAgICAgKi8KICAgIGNvbnN0IERhdGVJbnRl cnZhbEluZm8qIGdldERhdGVJbnRlcnZhbEluZm8odm9pZCkgY29uc3Q7CgoKICAgIC8qKgogICAg ICogU2V0IHRoZSBkYXRlIHRpbWUgaW50ZXJ2YWwgcGF0dGVybnMuIAogICAgICogQHBhcmFtIG5l d0ludGVydmFsUGF0dGVybnMgICB0aGUgZ2l2ZW4gaW50ZXJ2YWwgcGF0dGVybnMgdG8gY29weS4K ICAgICAqIEBkcmFmdCBJQ1UgMy45CiAgICAgKi8KICAgIHZvaWQgc2V0RGF0ZUludGVydmFsSW5m byhjb25zdCBEYXRlSW50ZXJ2YWxJbmZvJiBuZXdJbnRlcnZhbFBhdHRlcm5zKTsKCgogICAgLyoq CiAgICAgKiBSZXR1cm4gdGhlIGNsYXNzIElEIGZvciB0aGlzIGNsYXNzLiBUaGlzIGlzIHVzZWZ1 bCBvbmx5IGZvciBjb21wYXJpbmcgdG8KICAgICAqIGEgcmV0dXJuIHZhbHVlIGZyb20gZ2V0RHlu YW1pY0NsYXNzSUQoKS4gRm9yIGV4YW1wbGU6CiAgICAgKiA8cHJlPgogICAgICogLiAgIEJhc2Uq IHBvbHltb3JwaGljX3BvaW50ZXIgPSBjcmVhdGVQb2x5bW9ycGhpY09iamVjdCgpOwogICAgICog LiAgIGlmIChwb2x5bW9ycGhpY19wb2ludGVyLT5nZXREeW5hbWljQ2xhc3NJRCgpID09CiAgICAg KiAuICAgICAgIGVyaXZlZDo6Z2V0U3RhdGljQ2xhc3NJRCgpKSAuLi4KICAgICAqIDwvcHJlPgog ICAgICogQHJldHVybiAgICAgICAgICBUaGUgY2xhc3MgSUQgZm9yIGFsbCBvYmplY3RzIG9mIHRo aXMgY2xhc3MuCiAgICAgKiBAZHJhZnQgSUNVIDMuOQogICAgICovCiAgICBzdGF0aWMgVUNsYXNz SUQgVV9FWFBPUlQyIGdldFN0YXRpY0NsYXNzSUQodm9pZCk7CgogICAgLyoqCiAgICAgKiBSZXR1 cm5zIGEgdW5pcXVlIGNsYXNzIElEIFBPTFlNT1JQSElDQUxMWS4gUHVyZSB2aXJ0dWFsIG92ZXJy aWRlLiBUaGlzCiAgICAgKiBtZXRob2QgaXMgdG8gaW1wbGVtZW50IGEgc2ltcGxlIHZlcnNpb24g b2YgUlRUSSwgc2luY2Ugbm90IGFsbCBDKysKICAgICAqIGNvbXBpbGVycyBzdXBwb3J0IGdlbnVp bmUgUlRUSS4gUG9seW1vcnBoaWMgb3BlcmF0b3I9PSgpIGFuZCBjbG9uZSgpCiAgICAgKiBtZXRo b2RzIGNhbGwgdGhpcyBtZXRob2QuCiAgICAgKgogICAgICogQHJldHVybiAgICAgICAgICBUaGUg Y2xhc3MgSUQgZm9yIHRoaXMgb2JqZWN0LiBBbGwgb2JqZWN0cyBvZiBhCiAgICAgKiAgICAgICAg ICAgICAgICAgIGdpdmVuIGNsYXNzIGhhdmUgdGhlIHNhbWUgY2xhc3MgSUQuICBPYmplY3RzIG9m CiAgICAgKiAgICAgICAgICAgICAgICAgIG90aGVyIGNsYXNzZXMgaGF2ZSBkaWZmZXJlbnQgY2xh c3MgSURzLgogICAgICogQGRyYWZ0IElDVSAzLjkKICAgICAqLwogICAgdmlydHVhbCBVQ2xhc3NJ RCBnZXREeW5hbWljQ2xhc3NJRCh2b2lkKSBjb25zdDsKCnByb3RlY3RlZDoKCiAgICBEYXRlSW50 ZXJ2YWxGb3JtYXQoY29uc3QgRGF0ZUZvcm1hdCogZHRmbXQsIAogICAgICAgICAgICAgICAgICAg ICAgIGNvbnN0IERhdGVJbnRlcnZhbEluZm8qIGR0SXR2SW5mbywgCiAgICAgICAgICAgICAgICAg ICAgICAgVUVycm9yQ29kZSYgc3RhdHVzKTsKCnByaXZhdGU6CgoKICAgIERhdGVJbnRlcnZhbEZv cm1hdCgpOyAvLyBkZWZhdWx0IGNvbnN0cnVjdG9yIG5vdCBpbXBsZW1lbnRlZAoKICAgIC8qKgog ICAgICogaW5pdGlhbGl6ZXMgaW50ZXJ2YWwgcGF0dGVybnMgZ2l2ZW4gYSBsb2NhbGUgYW5kIGEg Y2FsZW5kYXIuCiAgICAgKiBAcGFyYW0gbG9jYWxlICAgICAgIExvY2FsZSBvZiB0aGUgc3ltYm9s cwogICAgICogQHBhcmFtIGNhbGVuZGFyICAgICBBbGlhcyB0byBDYWxlbmRhciB0aGF0IHdpbGwg YmUgdXNlZC4KICAgICAqIEBwYXJhbSBzdGF0dXMgICAgICAgRXJyb3IgY29kZQogICAgICovCiAg ICB2b2lkIGluaXRpYWxpemVJbnRlcnZhbEluZm8oY29uc3QgTG9jYWxlJiBsb2NhbGUsIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIENhbGVuZGFyKiBjYWxlbmRhciwgCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgVUVycm9yQ29kZSYgc3RhdHVzKTsKCgogICAgLyoqCiAg ICAgKiBUaGUgaW50ZXJ2YWwgcGF0dGVybnMgZm9yIHRoaXMgZm9ybWF0dGVyLgogICAgICovCiAg ICBEYXRlSW50ZXJ2YWxJbmZvKiAgICAgZkludGVydmFsUGF0dGVybjsKCiAgICAvKioKICAgICAq IFRoZSBEYXRlRm9ybWF0IG9iamVjdCB1c2VkIHRvIGZvcm1hdCBzaW5nbGUgcGF0dGVybgogICAg ICovCiAgICBEYXRlRm9ybWF0KiAgICAgICAgICAgICAgIGZEYXRlRm9ybWF0OwoKICAgIC8qKgog ICAgICogVGhlIDIgY2FsZW5kYXJzIHdpdGggdGhlIGZyb20gYW5kIHRvIGRhdGUKICAgICAqLwog ICAgQ2FsZW5kYXIqIGZGcm9tQ2FsZW5kYXI7CiAgICBDYWxlbmRhciogZlRvQ2FsZW5kYXI7Cn07 CgogClVfTkFNRVNQQUNFX0VORAoKI2VuZGlmIC8qICNpZiAhVUNPTkZJR19OT19GT1JNQVRUSU5H ICovCgojZW5kaWYgLy8gX0RUSVRWRk1UX0hfXwovL2VvZgo= |
|
From: George R. <gr...@us...> - 2008-01-24 03:35:38
|
Here are my comments on the new API. 1) Please change all @draft 3.9 to @draft 4.0. There is no 3.9.0 release. = ICU 4.0 is the reference release this API will appear in. 2) Please do define virtual functions inline, like operator!=3D. Virtual=20 functions can't be inlined. Defining the virtual functions in the .cpp=20 file will solve this problem. 3) There is no need to forward declare DateIntervalFormat and=20 MessageFormat in dtitvfmt.h. Please delete them. 4) The assignment operator and copy constructors for DateIntervalFormat=20 don't make sense. DateIntervalFormat isn't derived from SimpleDateFormat. = It's derived from Format. Is this a typo? 5) The createInstance functions takes a DateFormat object as a parameter,=20 but the documentation says it should be a SimpleDateFormat. If it must be = a SimpleDateFormat with a pattern, why not make those factory methods take = a SimpleDateFormat? Do you predict that this code will be using a=20 non-simple dateformat in the future, like a RuleBasedDateFormat in the=20 future? 6) The constructor DateIntervalInfo(const Locale& locale, const char*=20 type, UErrorCode& status) and DateIntervalInfo(const Locale& locale, const = char* type, const UnicodeString& skeleton, UErrorCode& status) are very=20 bad API. It depends on the Calendar::getType() function, which is an=20 @internal function. In ICU4C, calendars are specified as a part of the=20 locale. If you need more information from a Calendar, and a locale is=20 insufficient, maybe you can pass in the calendar instead of the calendar=20 type. Please remove or change this specific API. 7) I see that DateIntervalInfo::setIntervalPattern uses a string for a=20 identifying the largest calendar unit difference. Is there a reason why=20 this isn't an enum, like UDateFormatField or UCalendarDateFields?=20 UCalendarDateFields would make more sense. Since there are predefined=20 fields that can used with this function, a free form UnicodeString=20 argument won't be as helpful. 8) Is there a plan for a C API? 9) Can you forward your DateInterval API proposal too? The API reference=20 mentions DateInterval as a pair of UDate, but I only see=20 DateIntervalFormat and DateIntervalInfo. 10) The API reference mentions "skeleton" being used in a few places. Was = there suppose to be a setter or a getter for a skeleton somewhere? While=20 I'm pretty sure I know what you mean by skeleton, new comers may not be so = familiar with skeleton patterns. So maybe you can add more documentation=20 on what these skeletons are all about. George Rhoten IBM Globalization Center of Competency/ICU San Jos=E9, CA, USA http://www.icu-project.org/ "xiaomei ji" <xia...@gm...>=20 Sent by: icu...@li... 01/21/2008 11:29 AM Please respond to icu...@li... To icu...@li... cc Subject Re: [icu-design] Proposal of Interval Date/Time Format Hi George, =20 My email send out last Friday got rejected since I attached 2 too large=20 doxygen generated document files. =20 I just started to design and implement it. And I have not checked in=20 anything yet. =20 Attached are 2 raw header files (mainly on the public API part) of=20 DateIntervalInfo and DateIntervalFormat. =20 They are 1st draft. And your comments are very welcomed. =20 Thanks, Xiaomei |
|
From: xiaomei j. <xia...@gm...> - 2008-01-24 20:23:25
|
Hi George, Thanks for your comments! Please see my reply below. On Jan 23, 2008 7:35 PM, George Rhoten <gr...@us...> wrote: > Here are my comments on the new API. > > 1) Please change all @draft 3.9 to @draft 4.0. There is no 3.9.0 release= . > ICU 4.0 is the reference release this API will appear in. done > > 2) Please do define virtual functions inline, like operator!=3D. Virtual > functions can't be inlined. Defining the virtual functions in the .cpp > file will solve this problem. changed DateIntervalFormat::operator!=3D() to non-virtual. > > 3) There is no need to forward declare DateIntervalFormat and > MessageFormat in dtitvfmt.h. Please delete them. done > > 4) The assignment operator and copy constructors for DateIntervalFormat > don't make sense. moved to protected > DateIntervalFormat isn't derived from SimpleDateFormat. > It's derived from Format. Is this a typo? Since DateIntervalFormat formats on 2 dates while SimleDateFormat formats o= n 1, We proposed DateIntervalFormat as a sub-class of Format, and it formats on = a new object -- DateInterval object, which encapsulates 2 UDate. > > 5) The createInstance functions takes a DateFormat object as a parameter, > but the documentation says it should be a SimpleDateFormat. If it must b= e > a SimpleDateFormat with a pattern, why not make those factory methods tak= e > a SimpleDateFormat? Do you predict that this code will be using a > non-simple dateformat in the future, like a RuleBasedDateFormat in the > future? We thought since many user create SimpleDateFormat using DateFormat factory method, so, instead of asking users to downcast, we will do downcast internally. For now, underlying, the code checks whether the DateFormat is a SimpleDateFormat or not and do downcast accordingly. > > 6) The constructor DateIntervalInfo(const Locale& locale, const char* > type, UErrorCode& status) and DateIntervalInfo(const Locale& locale, cons= t > char* type, const UnicodeString& skeleton, UErrorCode& status) are very > bad API. It depends on the Calendar::getType() function, which is an > @internal function. In ICU4C, calendars are specified as a part of the > locale. If you need more information from a Calendar, and a locale is > insufficient, maybe you can pass in the calendar instead of the calendar > type. Please remove or change this specific API. removed. > > 7) I see that DateIntervalInfo::setIntervalPattern uses a string for a > identifying the largest calendar unit difference. Is there a reason why > this isn't an enum, like UDateFormatField or UCalendarDateFields? > UCalendarDateFields would make more sense. Since there are predefined > fields that can used with this function, a free form UnicodeString > argument won't be as helpful. changed to UCalendarDateFields > > 8) Is there a plan for a C API? Heard from Markus that I should, but I have not started yet. > 9) Can you forward your DateInterval API proposal too? The API reference > mentions DateInterval as a pair of UDate, but I only see > DateIntervalFormat and DateIntervalInfo. I will > > 10) The API reference mentions "skeleton" being used in a few places. Wa= s > there suppose to be a setter or a getter for a skeleton somewhere? While > I'm pretty sure I know what you mean by skeleton, new comers may not be s= o > familiar with skeleton patterns. So maybe you can add more documentation > on what these skeletons are all about. The skeleton is part of the mapping. The interval mapping is from (skeleton, largest different calendar field) t= o (pattern). Skeleton itself may not make much sense. I did not think of a usage that it needs to be set and get. If you have anything in mind, could you please let me know? But I will add more documentation on skeletons. Thanks, Xiaomei > > George Rhoten > IBM Globalization Center of Competency/ICU San Jos=E9, CA, USA > http://www.icu-project.org/ > > > > "xiaomei ji" <xia...@gm...> > Sent by: icu...@li... > 01/21/2008 11:29 AM > Please respond to > icu...@li... > > > To > icu...@li... > cc > > Subject > Re: [icu-design] Proposal of Interval Date/Time Format > > > > > > > Hi George, > > My email send out last Friday got rejected since I attached 2 too large > doxygen generated document files. > > I just started to design and implement it. And I have not checked in > anything yet. > > Attached are 2 raw header files (mainly on the public API part) of > DateIntervalInfo and DateIntervalFormat. > > They are 1st draft. And your comments are very welcomed. > > Thanks, > Xiaomei > > > ------------------------------------------------------------------------- > 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 > |
|
From: xiaomei j. <xia...@gm...> - 2008-01-25 01:37:49
|
Hi George, The DateInterval file is at http://bugs.icu-project.org/trac/browser/icu/branches/xji/intervalformat/so= urce/common/unicode/dtintrv.h Thanks, Xiaomei On Jan 23, 2008 7:35 PM, George Rhoten <gr...@us...> wrote: > Here are my comments on the new API. > > 1) Please change all @draft 3.9 to @draft 4.0. There is no 3.9.0 release= . > ICU 4.0 is the reference release this API will appear in. > 2) Please do define virtual functions inline, like operator!=3D. Virtual > functions can't be inlined. Defining the virtual functions in the .cpp > file will solve this problem. > 3) There is no need to forward declare DateIntervalFormat and > MessageFormat in dtitvfmt.h. Please delete them. > 4) The assignment operator and copy constructors for DateIntervalFormat > don't make sense. DateIntervalFormat isn't derived from SimpleDateFormat= . > It's derived from Format. Is this a typo? > 5) The createInstance functions takes a DateFormat object as a parameter, > but the documentation says it should be a SimpleDateFormat. If it must b= e > a SimpleDateFormat with a pattern, why not make those factory methods tak= e > a SimpleDateFormat? Do you predict that this code will be using a > non-simple dateformat in the future, like a RuleBasedDateFormat in the > future? > 6) The constructor DateIntervalInfo(const Locale& locale, const char* > type, UErrorCode& status) and DateIntervalInfo(const Locale& locale, cons= t > char* type, const UnicodeString& skeleton, UErrorCode& status) are very > bad API. It depends on the Calendar::getType() function, which is an > @internal function. In ICU4C, calendars are specified as a part of the > locale. If you need more information from a Calendar, and a locale is > insufficient, maybe you can pass in the calendar instead of the calendar > type. Please remove or change this specific API. > 7) I see that DateIntervalInfo::setIntervalPattern uses a string for a > identifying the largest calendar unit difference. Is there a reason why > this isn't an enum, like UDateFormatField or UCalendarDateFields? > UCalendarDateFields would make more sense. Since there are predefined > fields that can used with this function, a free form UnicodeString > argument won't be as helpful. > 8) Is there a plan for a C API? > 9) Can you forward your DateInterval API proposal too? The API reference > mentions DateInterval as a pair of UDate, but I only see > DateIntervalFormat and DateIntervalInfo. > 10) The API reference mentions "skeleton" being used in a few places. Wa= s > there suppose to be a setter or a getter for a skeleton somewhere? While > I'm pretty sure I know what you mean by skeleton, new comers may not be s= o > familiar with skeleton patterns. So maybe you can add more documentation > on what these skeletons are all about. > > George Rhoten > IBM Globalization Center of Competency/ICU San Jos=E9, CA, USA > http://www.icu-project.org/ > > > > "xiaomei ji" <xia...@gm...> > Sent by: icu...@li... > 01/21/2008 11:29 AM > Please respond to > icu...@li... > > > To > icu...@li... > cc > > Subject > Re: [icu-design] Proposal of Interval Date/Time Format > > > > > > > Hi George, > > My email send out last Friday got rejected since I attached 2 too large > doxygen generated document files. > > I just started to design and implement it. And I have not checked in > anything yet. > > Attached are 2 raw header files (mainly on the public API part) of > DateIntervalInfo and DateIntervalFormat. > > They are 1st draft. And your comments are very welcomed. > > Thanks, > Xiaomei > > > ------------------------------------------------------------------------- > 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 > |
Thanks for helping keep SourceForge clean.
X