-
Notifications
You must be signed in to change notification settings - Fork 215
Isomorphic time format issue #109
Comments
Isn't it the clients native implementation which is wrong? Which client are you testing on? https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat Valid values is |
@danieljuhl, the options passed are merely hints at the format you want. Ultimately it depends on the pattern that is resolved from the locale data. Upon investigation, it appears this is a pretty complicated issue and perhaps even a spec issue. The spec defines internal descriptors for patterns that look like this: {
"hour": "numeric",
"minute": "2-digit",
"pattern": "{hour}:{minute}",
"pattern12": "{hour}:{minute} {ampm}"
} CLDR data is precompiled to this format for the polyfill to reduce complexity in the production code, optimising speed of formatting and keeping the library code small. In the CLDR data, 24-hour and 12-hour patterns are described separately:
This is from I'm not sure how we should deal with this in the short term. Our options look like this:
|
@andyearnshaw yes, I did a similar research yesterday for #108, and found that in deed, CLDR data covers only a subset of what browsers implements today. In the case of
and that is coming from:
Clearly, there is no hours/minutes pattern with hours using the 2-digits pattern. But also I noticed that I'm not generating any value with
I will try to workout the details today. |
Fixes #109: set hour12 default value for each cldr date format patterns
@danieljuhl @Ekhoo go ahead and try intl@1.0.0-rc-2 |
@caridy Thanks, I'll test it tomorrow morning central european time. |
@caridy I still have the problem :/ |
@danieljuhl @Ekhoo are you guys trying intl@1.0.0-rc-4? |
I tried the |
Any news about this one guys? |
@shouze I haven't get a chance to work on this. I have some ideas, in case someone wants to try to bake in a solution. Feel free to reach out to me. |
@caridy can you expose your ideas? How can I (or my team) help you? |
check your gmail :) |
@caridy sorry I've been very busy maybe this will be ok the coming week. |
yes, will be perfect since it is the TC39 week, which means I will be working on Intl stuff all week :) |
Hi, I'm experiencing same behavior on both |
Me too: Using:
I am getting a warning in react saying the server is rendering the formatted date differently than what is rendered on the client. I am running the server and client on the same machine (currently). How can I ensure the date is rendered the same?
|
@rkoberg this is a big problem when it comes to isomorphic apps, if the env diverge, the rehydration checks might fail. In this particular case, you can probably use this branch, https://github.com/andyearnshaw/Intl.js/tree/cldr-refactor, and let us know if that helps. I plan to release that in a couple of weeks. As for the observable differences that might occur between the server and client with respect to react-intl, I have been discussing it with @ericf, and we might be able to solve it at react level, forcing react to ignore differences in the content of a react-intl component. But that might take a while to land. |
Fixed by PR #146, shipped in intl@1.1.0 |
I use
react-intl
and we have a time format issue with the polyfill version.See => here
(Using react-intl, polyfill on server, native on client)
With the
fr-FR
locale, I have a format issue with the<FormattedTime />
component.If I have a date like this one:
2015-06-17T06:00:00+0000
:Server rendering =>
8:00
Client rendering =>
08:00
I use this format:
The text was updated successfully, but these errors were encountered: