Allow multiple patterns for date formats

Allow multiple patterns for date formats
Committed: https://code.google.com/p/dart/source/detail?r=11114

[Alan Knight, 2012-08-21 21:40:01]

This adds the ability to specify multiple formats on a date, e.g. to support
printing year/month/day hour:minute:second from a single format.

It was difficult to come up with something reasonable to type and not subject to
much confusion. I ended up adding instance methods for each skeleton, so you can
write
  new DateFormat.yMd().hms()
There's also an explicit addPattern() method so you can add an arbitrary
pattern, and the ability to specify an arbitrary separator between the two
formats (by default, a space).

To avoid duplicate work if you do this, made parsing of the pattern be lazy.

[Emily Fortuna, 2012-08-21 22:17:02]

Does closure have this functionality? It seems a little unusual -- how does it
play with RTL languages instead of LTR?

https://chromiumcodereview.appspot.com/10832430/diff/2001/pkg/intl/date_forma...
File pkg/intl/date_format.dart (right):

https://chromiumcodereview.appspot.com/10832430/diff/2001/pkg/intl/date_forma...
pkg/intl/date_format.dart:361: DateFormat EEEE() => addPattern("EEEE");
is it really that helpful to explicitly add all these extra methods? I think if
you're adding methods to make a new combo-pattern, the user might as well just
say "addPattern("LLL")"

https://chromiumcodereview.appspot.com/10832430/diff/2001/pkg/intl/date_forma...
pkg/intl/date_format.dart:466: get _formatFields() {
Dart2js will complain about this getter syntax (no parens anymore)

https://chromiumcodereview.appspot.com/10832430/diff/2001/pkg/intl/date_forma...
pkg/intl/date_format.dart:500: _pattern = "$_pattern$separator$inputPattern";
bidi?

https://chromiumcodereview.appspot.com/10832430/diff/2001/pkg/intl/date_forma...
pkg/intl/date_format.dart:520: // If we had already parsed the format fields,
reset them.
had => have

https://chromiumcodereview.appspot.com/10832430/diff/2001/pkg/intl/test/date_...
File pkg/intl/test/date_time_format_test.dart (right):

https://chromiumcodereview.appspot.com/10832430/diff/2001/pkg/intl/test/date_...
pkg/intl/test/date_time_format_test.dart:186: 
extra whitespace here?

[Alan Knight, 2012-08-21 23:18:05]

Closure is a more limited set of formats, and includes hard-coded
FULL_DATE_TIME, which is roughly equivalent to yMd().hms()

This is also one of the things that the internationalization people asked for -
though their idea was to have three patterns in the constructor, all optional. I
didn't like that because it was very awkward to have that as well as the
optional locale, where everything is strings.

https://chromiumcodereview.appspot.com/10832430/diff/2001/pkg/intl/date_forma...
File pkg/intl/date_format.dart (right):

https://chromiumcodereview.appspot.com/10832430/diff/2001/pkg/intl/date_forma...
pkg/intl/date_format.dart:361: DateFormat EEEE() => addPattern("EEEE");
On 2012/08/21 22:17:03, Emily Fortuna wrote:
> is it really that helpful to explicitly add all these extra methods? I think
if
> you're adding methods to make a new combo-pattern, the user might as well just
> say "addPattern("LLL")"

If my mental model is of the format as ymd hms it seems a lot more pleasant to
write 
  ...yMd().hms();
than
  ...yMd().addPattern("hms");

https://chromiumcodereview.appspot.com/10832430/diff/2001/pkg/intl/date_forma...
pkg/intl/date_format.dart:466: get _formatFields() {
On 2012/08/21 22:17:03, Emily Fortuna wrote:
> Dart2js will complain about this getter syntax (no parens anymore)
It doesn't complain right now on my machine, and it doesn't seem to complain on
the buildbots or everything would be red, since there are at least a dozen
getters in intl, and it looks like there are others in other packages. At what
point is it going to start rejecting this, and is it just going to result in
massive build breakage, or is somebody going to go and change all the libraries
at once? I'd say let's do a separate CL to change them all at once, unless
someone is going to do them library-wide.

https://chromiumcodereview.appspot.com/10832430/diff/2001/pkg/intl/date_forma...
pkg/intl/date_format.dart:500: _pattern = "$_pattern$separator$inputPattern";
On 2012/08/21 22:17:03, Emily Fortuna wrote:
> bidi?

It's my impression that even in Bidi languages, the date formats go left to
right. They may, though I'm not sure, have things like month names going RTL.
This is exactly what Closure does (except they hard-code the space separator,
and have a smaller set of formats).  See applyStandardPattern.

https://chromiumcodereview.appspot.com/10832430/diff/2001/pkg/intl/date_forma...
pkg/intl/date_format.dart:520: // If we had already parsed the format fields,
reset them.
On 2012/08/21 22:17:03, Emily Fortuna wrote:
> had => have

Done.

https://chromiumcodereview.appspot.com/10832430/diff/2001/pkg/intl/test/date_...
File pkg/intl/test/date_time_format_test.dart (right):

https://chromiumcodereview.appspot.com/10832430/diff/2001/pkg/intl/test/date_...
pkg/intl/test/date_time_format_test.dart:186: 
On 2012/08/21 22:17:03, Emily Fortuna wrote:
> extra whitespace here?

Done.

[Emily Fortuna, 2012-08-21 23:46:03]

lgtm!

Re: bidi -- sgtm!

https://chromiumcodereview.appspot.com/10832430/diff/2001/pkg/intl/date_forma...
File pkg/intl/date_format.dart (right):

https://chromiumcodereview.appspot.com/10832430/diff/2001/pkg/intl/date_forma...
pkg/intl/date_format.dart:361: DateFormat EEEE() => addPattern("EEEE");
On 2012/08/21 23:18:05, Alan Knight wrote:
> On 2012/08/21 22:17:03, Emily Fortuna wrote:
> > is it really that helpful to explicitly add all these extra methods? I think
> if
> > you're adding methods to make a new combo-pattern, the user might as well
just
> > say "addPattern("LLL")"
> 
> If my mental model is of the format as ymd hms it seems a lot more pleasant to
> write 
>   ...yMd().hms();
> than
>   ...yMd().addPattern("hms");
> 
sgtm

https://chromiumcodereview.appspot.com/10832430/diff/2001/pkg/intl/date_forma...
pkg/intl/date_format.dart:466: get _formatFields() {
On 2012/08/21 23:18:05, Alan Knight wrote:
> On 2012/08/21 22:17:03, Emily Fortuna wrote:
> > Dart2js will complain about this getter syntax (no parens anymore)
> It doesn't complain right now on my machine, and it doesn't seem to complain
on
> the buildbots or everything would be red, since there are at least a dozen
> getters in intl, and it looks like there are others in other packages. At what
> point is it going to start rejecting this, and is it just going to result in
> massive build breakage, or is somebody going to go and change all the
libraries
> at once? I'd say let's do a separate CL to change them all at once, unless
> someone is going to do them library-wide.

Yeah, I made this comment because just yesterday I had to put in a CL that got
rid of the old getter syntax on the Dromaeo tests (because my bots were
breaking), but I've been talking to others, and while the feature is
implemented, no one else seems to be having the problem of it flat-out not
working. So -- carry on until it becomes an issue!