Polish Date formatting API.

Polish Date formatting API.
Committed: https://code.google.com/p/dart/source/detail?r=8272

[Emily Fortuna, 2012-06-02 01:56:57]

This CL is not in its final state. I'll complete it once your CL is in. (as
written the tests won't run since it doesn't have the Intl class yet)

[Alan Knight, 2012-06-03 17:19:52]

https://chromiumcodereview.appspot.com/10505005/diff/2001/lib/i18n/date_forma...
File lib/i18n/date_format.dart (right):

https://chromiumcodereview.appspot.com/10505005/diff/2001/lib/i18n/date_forma...
lib/i18n/date_format.dart:101: #library('DateTimeFormat');
I had deliberately called it DateFormat, rather than DateTimeFormat, on the
basis that the things it operates on are of class Date, and we don't have Time
or DateTime.

https://chromiumcodereview.appspot.com/10505005/diff/2001/lib/i18n/date_forma...
lib/i18n/date_format.dart:135: DateTimeFormat(this.formatDefinition,
[this._locale]) {
Should we allow formatDefinition to also be optional so you can just ask for a
new instance with a default format? Or would that then force people to use names
on the arguments? It might be that that use case is supported once we have the
Intl object and they can just ask for a default instance that way.

https://chromiumcodereview.appspot.com/10505005/diff/2001/tests/lib/i18n/date...
File tests/lib/i18n/date_format_test.dart (right):

https://chromiumcodereview.appspot.com/10505005/diff/2001/tests/lib/i18n/date...
tests/lib/i18n/date_format_test.dart:27: date_format = new
DateFormat(DateFormat.Hms);
This puts us back to having the extra DateFormat that Vijay wanted to avoid by
having the named constructors. Maybe we should support new DateFormat.hms()??

These tests clearly won't run because they use DateFormat and it was renamed,
but I presume that comes as part of the TODO at the top.

[Emily Fortuna, 2012-06-04 22:48:48]

PTAL

I'm not sure if we want to have named constructors AND contstants for maximum
discoverability? (perhaps a bit redundant...)

I made the changes you suggested from the "previously closed" CL here. This may
need a little more tweaking after our meeting.

https://chromiumcodereview.appspot.com/10505005/diff/6001/lib/i18n/date_forma...
File lib/i18n/date_format.dart (right):

https://chromiumcodereview.appspot.com/10505005/diff/6001/lib/i18n/date_forma...
lib/i18n/date_format.dart:158: static final String _longTime = DateFormat.Hms +
'a zzzz';
This will probably be fixed up after we have our meeting on Time Zones in a few
min.

[Alan Knight, 2012-06-04 23:59:00]

https://chromiumcodereview.appspot.com/10505005/diff/9003/lib/i18n/date_forma...
File lib/i18n/date_format.dart (right):

https://chromiumcodereview.appspot.com/10505005/diff/9003/lib/i18n/date_forma...
lib/i18n/date_format.dart:117: * formatted (such as en).
I think this is still not right. It's the locale, not the language, that
determines how things are formatted. So en-US and en-CA are different.

https://chromiumcodereview.appspot.com/10505005/diff/9003/lib/i18n/date_forma...
lib/i18n/date_format.dart:158: static final String _fullDate = DateFormat._y +
DateFormat._MMMMd;
I thought we don't have String + any more.

https://chromiumcodereview.appspot.com/10505005/diff/9003/lib/i18n/date_forma...
lib/i18n/date_format.dart:160: static final String _mediumDate = DateFormat._y +
DateFormat._Md;
Couldn't we just write these as e.g. _y + _Md, since we're inside the DateFormat
class?

https://chromiumcodereview.appspot.com/10505005/diff/9003/lib/i18n/date_forma...
lib/i18n/date_format.dart:174: * constant and the parsing was lazy.
I think the last two lines of this comment are obsolete.

[Emily Fortuna, 2012-06-05 00:21:50]

PTAL

https://chromiumcodereview.appspot.com/10505005/diff/9003/lib/i18n/date_forma...
File lib/i18n/date_format.dart (right):

https://chromiumcodereview.appspot.com/10505005/diff/9003/lib/i18n/date_forma...
lib/i18n/date_format.dart:158: static final String _fullDate = DateFormat._y +
DateFormat._MMMMd;
On 2012/06/04 23:59:00, Alan Knight wrote:
> I thought we don't have String + any more.

Yup. old habits die hard. Fixed.

https://chromiumcodereview.appspot.com/10505005/diff/9003/lib/i18n/date_forma...
lib/i18n/date_format.dart:160: static final String _mediumDate = DateFormat._y +
DateFormat._Md;
On 2012/06/04 23:59:00, Alan Knight wrote:
> Couldn't we just write these as e.g. _y + _Md, since we're inside the
DateFormat
> class?

Duh! fixed!

https://chromiumcodereview.appspot.com/10505005/diff/9003/lib/i18n/date_forma...
lib/i18n/date_format.dart:174: * constant and the parsing was lazy.
On 2012/06/04 23:59:00, Alan Knight wrote:
> I think the last two lines of this comment are obsolete.

Done.

[Jennifer Messerly, 2012-06-05 01:28:55]

lgtm

https://chromiumcodereview.appspot.com/10505005/diff/20001/lib/i18n/date_form...
File lib/i18n/date_format.dart (right):

https://chromiumcodereview.appspot.com/10505005/diff/20001/lib/i18n/date_form...
lib/i18n/date_format.dart:174: DateFormat.Hm([this._locale]) :
this.formatDefinition = _Hm;
minor nit: you shouldn't need "this." initializer lists.

[Alan Knight, 2012-06-05 17:35:52]

https://chromiumcodereview.appspot.com/10505005/diff/10006/lib/i18n/date_form...
File lib/i18n/date_format.dart (right):

https://chromiumcodereview.appspot.com/10505005/diff/10006/lib/i18n/date_form...
lib/i18n/date_format.dart:247: * reference [date]. The [duration] is expressed
in miliseconds.
Really minor nit - milliseconds (two "l"s)

https://chromiumcodereview.appspot.com/10505005/diff/10006/lib/i18n/date_form...
lib/i18n/date_format.dart:249: String formatDurationFrom(num duration, Date
date) {
We seem to have a Duration type in core, should we use that instead of just a
number? And if not, we should probably call the variable something like
"milliseconds" rather than "duration".

[Alan Knight, 2012-06-05 19:52:24]

lgtm