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.: https://github.com/tc39/ecma402/issues/108 <https://github.com/tc39/ecma402/issues/108>, 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 https://github.com/tc39/ecma402/ <https://github.com/tc39/ecma402/> :) ./caridy > On Sep 21, 2017, at 11:58 PM, Darien Valentine <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
