I’ve spent a good month on a similar problem about localization in my previous job. But on Dates. Few thoughts on the topic:
Modern browsers ship with Intl. However the way its supported is still poor. There are differences across vendors, difference across versions (safari & nightly), and the polyfill (Intl.js) sadly has a good number of bugs. And this is just for the formatting. If you also want to parse from your display format, across different browsers, with russian, chinese and so on, it’s an uphill battle. Moment parsing was not good enough for my case, I think the best parsing lib I did find was Sugar.js.
It is hard to describe how messy the field is until you put your hands in it.
Finally, I ended up writing a dumbed down version of both parser and formatter, because designers could not live without a specific non-standard separator in a specific language in all the browsers.
And still, you have to deal with stuff like Feb/31 being correctly parsed by JS to march 2 (this year!!) and UX that will want to throw an error to the user, and cry when you don’t match his AC.
here’s few lesson learned:
1: avoid any designer/UX/Prod involvement in a datefield for as long as you can. OR be clear on what an MVP is.
2: test parsing through your format for one full year for all your locales. (Pseudopython follows)
for x in formats:
for day in year:
assert format('iso' day) == format('iso' parse(format(x), day ))
I’ve spent a good month on a similar problem about localization in my previous job. But on Dates. Few thoughts on the topic: Modern browsers ship with Intl. However the way its supported is still poor. There are differences across vendors, difference across versions (safari & nightly), and the polyfill (Intl.js) sadly has a good number of bugs. And this is just for the formatting. If you also want to parse from your display format, across different browsers, with russian, chinese and so on, it’s an uphill battle. Moment parsing was not good enough for my case, I think the best parsing lib I did find was Sugar.js.
It is hard to describe how messy the field is until you put your hands in it. Finally, I ended up writing a dumbed down version of both parser and formatter, because designers could not live without a specific non-standard separator in a specific language in all the browsers. And still, you have to deal with stuff like Feb/31 being correctly parsed by JS to march 2 (this year!!) and UX that will want to throw an error to the user, and cry when you don’t match his AC. here’s few lesson learned:
1: avoid any designer/UX/Prod involvement in a datefield for as long as you can. OR be clear on what an MVP is. 2: test parsing through your format for one full year for all your locales. (Pseudopython follows)
I still scratch my head as to why platforms don’t offer better APIs for dates and times. The fact that moment needs to exist baffles me.