Consider date formatting

Caridy Patiño caridy at
Fri Sep 22 14:56:08 UTC 2017

Intl.DateTimeFormat is a low level API that is very powerful, and we will continue evolving it. Intl.DateTimeFormat.prototype.formatToParts is just one more thing that we have added recently (stage 4). Patterns, and Skeletons (which are not the same) have been a topic of discussion many times, e.g.: <>, and I hope we can continue those discussions.

Unfortunately, pattern seems to be a foot gun. It is only really useful to folks with a very specific requirement per locale, which means they need to define the pattern that they want per locale, and that sort of conflicts with the philosophy behind DateTimeFormat, and not many people realize that.

OTOH, skeleton is pretty much equivalent to what we have today via options, whether it has better ergonomics is debatable IMO. Additionally, Mozilla folks have been proposing some reforms to introduce a more simple form of skeleton that matches the OS configuration.

Bottom line, we are progressing in various fronts (date manipulation and formatting), and these are very exciting times for anyone who is interested in these topics, just come and help us in <> :)


> On Sep 21, 2017, at 11:58 PM, Darien Valentine <valentinium at> wrote:
> I think there is a pretty good case to be made for native support for pattern-based formatting as the OP described. I believe it has prior art in other languages and, while the highly configurable, internationalized formatting provided by `Intl.DateTimeFormat.prototype.format` is very valuable, pattern-based formatting serves different purposes.
> @ Maggie I’m very excited to see ES getting distinct, hack-free types for representing the different kinds of date/date time values that we often awkwardly conflate with the generic datetime Date. The immutability is refreshing — I cannot think of a time I ever thought "gee, I’m glad date objects are mutable".
> @ kai zhu, I appreciate the perspective you try to bring to things on these forums, but I don’t think that your campaign for simplicity is well-served by arguing that people should roll their own date manipulation utilities. :) In many cases, it’s true that one needs nothing more than Date, and it’s also been my experience that sometimes when people think "but timezones!" they are creating, not solving, problems. However, cases that do demand more nuance aren’t uncommon, and when you wrote that date arithmetic is "trivial to do with 3-lines of vanilla javascript code", ten thousand dead developers briefly reanimated in their graves and hissed demonic curses.
> _______________________________________________
> es-discuss mailing list
> es-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list