Added Area-Library, Triaged labels.

I'm going to call this a duplicate of 3953, providing internationalization/localization. So right now the equivalent of what you're asking for would be

  new DateFormat("E").format(new Date.now());

though with the additional cost that you'd need to have done an async

  initializeDateFormatting('en_US', null)

somewhere previously. It has the advantage that the set of skeletons come from ICU and are reasonably well-defined, and that they will adapt to other locales, so if your default locale was something else it would print appropriately for it. But it isn't printf-like, so it doesn't fit into strings quite as easily.

Set owner to @alan-knight.
Added Duplicate label.
Marked as being merged into #3953.

This comment was originally written by chris.eee...@gmail.com

Just to play devil's advocate, the underlying strftime C library is also locale aware. Maybe it's the old C/Perl/Ruby hacker in me, but to get the locale specific abbreviated day of the week, I much prefer:

date.strftime('%a');

To:

new DateFormat("E").format(date);

There is less cluttering up the intent of the code--at least to my eye. Even if strftime is just a wrapper around DateFormat, I would like to see strftime make it into Dart.

This comment was originally written by gouttonio@gmail.com

Then, why keep the strftime, and not go directly for format ?

date.format('whatever');

As long as the "whatever" part is heavily documented...
The thing to ask ourselves is : "Is there any ambiguity that the returned type of format is a string ? If not, do we need to keep the str in the function name ?"

Consistency with existing languages is important to flatten the learning curve. But evolution towards elegance is important too !

Just my 2 cents.

I would love to see this opened back up. It's never too late for Dart to start using the same DateTime string formatting syntax that the rest of the world uses. Dart is going against huge ubiquity here. There are good reasons that some things C never die.