Related to #124 and #117

If we do it for month names then we probably ought to do it for weekdays too. It's probably best to only include this data where it differs from the standard format so as not to unnecessarily increase the JSON file sizes for most languages.

I will be happy to take this, but we need to run some tests to see how much data are we talking about here. As for the 402 spec, I think we are covered by https://tc39.github.io/ecma402/#sec-formatdatetime 12.1.6.13.a.ix, specifically, this sentence:

ix. Else if f is "narrow", "short", or "long", then ... If p is "month", then the String value may also depend on whether dateTimeFormat has a [[day]] internal slot. If p is "timeZoneName", then the String value may also depend on the value of the [[inDST]] field of tm, ...

It doesn't say anything about quarters or weekdays. Do you think we should include that in the specification? /cc @srl295 @JCEmmons

I am using react-intl@2.0.0-beta for client and server. Right now server-rendering (with Intl polyfill) differs from browser (build-in Intl).

@ericf I use something like this

<FormattedDate
    value={new Date(exper.start)}
    month="long"
    year="numeric"
/>

So I think for isomorphic JS applications it is very important to have correct cases for months and weeks. Regardless to file sizes.

May be you can build second npm module with all cases? And give it name, something like intl-huge.

@nodkz checksum will always be a problem when rehydrating. in the past I remember some conversations with some react folks to allow holes in the checksum verification process for cases like this where the rehydration might attempt to change the value. I also remember something about the formatjs components opting out of the update for the first rehydration.

Guys, any plans when it will be fixed?