Re: [icu-design] Proposal of Interval Date/Time Format

[xiaomei j. <xia...@gm...>]

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.