Intl.js
Intl.js copied to clipboard
andyearnshaw
91% of formatted dates differ from native implementation
Since I had faced https://github.com/andyearnshaw/Intl.js/issues/117 formatting issue, I created a simple check suite of native and polyfill implementation and it revealed that 5313 from 5831 formatted dates are different from native ones (https://jsbin.com/wekebe/edit?js,output, check Chrome dev console)
Could be the Intl.js improved to fit at least 50% of variations?
Whilst fixing this, it might be worth including this code as a regression test suite with an automatic fail if we don't achieve above a certain threshold. I've been wanting to write some regression tests for a while now, it didn't occur to me to check all permutations against the native implementation that's shipped with node v0.12.
V8's Intl still fails a few of DateTimeFormat tests, but I think those are more or less superficial.
I do have a test suite locally that I was planning to commit. Will try to get that in soon. @jasonmit was also going to help with that.
Yes, it would be great to see in test results something more meaningful than
9.2.1_1
9.2.1_3
9.2.1_4
9.2.1_8_c_ii
9.2.1_8_c_vi
9.2.2
@vectart those are generated tests for every step of the algo based on the specifications, we will just add other tests to verify cldr data, and compare with native.
@vectart: those tests are incredibly useful. Although they don't assume any specific locales are supported (or that we're even using CLDR), they ensure that the bare minimum of required date/time formats are supported, the correct options are resolved for formatters, tags are properly canonicalised and matched and much more.
That being said, Intl.js has sorely needed some tests to prevent locale data-based regressions for a long time.
@andyearnshaw How was the bare minimum of required date/time formats defined if such basic formats doesn't work?
https://github.com/andyearnshaw/Intl.js/issues/117 { month: 'long' }
https://github.com/andyearnshaw/Intl.js/issues/126 { month: 'long' }
https://github.com/andyearnshaw/Intl.js/issues/125 { weekday: 'long' }
I really want to use Intl.js but seems it's better to fallback to Moment.js, Globalize or other more stable date-formatting library.
From the spec, section 12.2.3:
The following subsets must be available for each locale:
- weekday, year, month, day, hour, minute, second
- weekday, year, month, day
- year, month, day
- year, month
- month, day
- hour, minute, second
- hour, minute
Initially, we only supported one pattern for each of those subsets, the bare minimum to meet the spec's requirements, pass the tests and cover the majority of use cases. @caridy is working on improving the date formats—have a little patience (or feel free to contribute :wink:).
with the v1.1.0 release, we are down to 60%, big improvements. Now I'm seeing 3505 from 5831 failed in FF and Chrome.
with the v1.2.0 release, we are down to 0%, impressive. Now I'm seeing 0 from 5831 failed in FF and Chrome.
fixed by https://github.com/andyearnshaw/Intl.js/issues/171
update: this is not fixed yet.
@vectart something happen when attempting to test your test, I ended up copying that as part of the automation process, and I still see a bunch of differences, some of them, the polyfill is doing the right thing, while browsers take shortcut, but in general, we will have to continue this effort to close the gap. that 0% was very smelly :(, but let's keep targeting something like 20%.