Consider removing the dateSymbol type about proposal-intl-displaynames HOT 8 CLOSED

Because of 1 and 2, the case for having them in the API isn't very strong.

I don't understand that statement. How is the fact that a display name of a month in gregorian calendar never changes related to whether it's a good idea to expose it directly via Intl.DisplayNames?

Item 3 shows a major drawback to including them: their presence may entice uninformed developers to try to build their own date formatters, which would almost certainly be less correct and less performant than the date formatters already present in JavaScript.

I don't understand that statement. Intl.DateTimeFormat formats the date. Intl.DisplayNames exposes display names of some tokens. I don't see how any user would take an output of DisplayNames and attempt to construct datetime formatted pattern out of it instead of using Intl.DateTimeFormat for that.

from proposal-intl-displaynames.

It reduces the number of sources of truth from “every website” to “every browser/engine” - imo that’s a strong enough argument due to the lessened likelihood of the info being wrong.

from proposal-intl-displaynames.

This seems like a "philosophical" disagreement: do we withhold tools from users because we fear that they might be misused, or do we give them the tools and trust that programmers know to do the right thing? It's not too different from Intl.Segmenter line-type (tc39/proposal-intl-segmenter#49).

For what it's worth, I tend to prefer to expose all of the tools, but help the programmer by making the "right way" of doing things easier than the "wrong way". Intl.DateTimeFormat is already stable and extremely easy to use via Date.prototype.toLocaleString, which meets this mark, so on this particular issue I prefer exposing the date symbols.

from proposal-intl-displaynames.

As a use case, this feature allows implementing custom compact multilingual datetime selectors without headache. Shipping this data with component will increase its size by ~5-10 KiB (for each language) of gzipped size; I think it’s too much for one UI component.

Also, are Gregorian months enough? Why not consider 'month#' syntax (as for quarters)?

What about eras, Chinese zodiac?

from proposal-intl-displaynames.

Every API can be abused; this issue is not about withholding every API that has any possibility of abuse. Instead, this is about how likely abuse will be. An API that is easier to abuse than use correctly wouldn’t be a good API. I’m not claiming that dateSymbol is easier to abuse than not; just that the balance is perhaps too close.

I was responding to an argument made in the most recent telecon about how this API allows every website can be automatically updated when these strings change. The dateSymbol strings almost never change, so that argument isn’t particularly strong in this case.

from proposal-intl-displaynames.

Would this be worth discussing in an ECMA-402 meeting? Or have you concluded to remove these strings?

from proposal-intl-displaynames.

Close this issue based on ecma402 meeting conclusion

from proposal-intl-displaynames.

@FrankYFTang Could you summarize that conclusion here?

from proposal-intl-displaynames.