arrow
arrow copied to clipboard
Add ability to use CLDR
Feature Request
Add the ability to use CLDR in Arrow for locales to replace and/or supplement the current ones.
CLDR updates can be frequent, so packaging this in Arrow as an extras_require, where a user can update the definitions separately from Arrow and not overwhelm Arrow with many frequent releases would be ideal.
Example: https://unicode-org.github.io/cldr-staging/charts/37/verify/dates/mk.html as an example of what data points CLDR has for the Macedonian language
CLDR has a lot of other data points that we can use to improve Arrow, such as date time formatting, intervals, different calendar support, time zones, humanize support, etc.
coming from the land of the dateparser module, i will say to be careful in how you implement this. large datasets like this tend to impact run (and sometimes particularly load) time significantly. right now, arrow loads in a few miliseconds and it would be a shame to ruin that. ;)
anarcat@angela:~(main)$ multitime -n 10 -s 0 python3 -c 'True'
===> multitime results
1: python3 -c True
Mean Std.Dev. Min Median Max
real 0.025 0.010 0.022 0.022 0.054
user 0.020 0.007 0.014 0.019 0.037
sys 0.005 0.005 0.000 0.007 0.017
anarcat@angela:~(main)$ multitime -n 10 -s 0 python3 -c 'import arrow'
===> multitime results
1: python3 -c "import arrow"
Mean Std.Dev. Min Median Max
real 0.046 0.010 0.041 0.042 0.076
user 0.039 0.009 0.030 0.036 0.063
sys 0.007 0.004 0.000 0.008 0.012
(that's an old arrow, 0.17 in debian stable, but still... i think latest releases are comparable)
@anarcat we were thinking of going with a more modular approach, to have this as an addon to arrow that can be loaded on demand instead of as a fully built-in feature with all the locales inside the main repo.
As CLDR updates quite often, we don't want to spam releases for a CLDR only update, but have a separate arrow-cldr lib that can follow as closely as possible while keeping the arrow lib free from all that clutter.
As a side effect to this, I was thinking of adding the ability for humanize to handle a custom locale class.
Currently, one has to add a custom locale class into the locale map and then use a string with humanize, dehumanize.
Thoughts?