LDML v45 leaves open how to handle precision with mixed units.
Description
Problem case
A programmer supplies an amount like 1.5254° degrees to a number formatter using unitPreferences. They also specify a certain precision (either a range of min/max decimal digits, or a range of min/max significant digits). For some locales, this turns into a mixed unit. The question is: how to apply the precision to the mixed units?
This can also happen with length (eg, 6 foot 2 inches), weight (3 lbs 9 oz), and other measures.
An implementation could apply the precision of a number formatter to the final unit. However, this mechanism has a couple of disadvantages, such as matching precision across user preferences. For example, suppose the input amount is 1.5254 and the precision is 2 decimals.
Locale A uses decimal degrees and gets 1.53°.
Locale B uses degrees, minutes, seconds, and gets 1° 31′ 31.44″
Locale B has far too precise a result compared to locales without mixed units: the equivalent of 1.52540 in precision, for 6 digits of accuracy instead of 3.
We could invent some special options for mixed units, but one of our primary goals is using unit preferences to handle the conversions and formatting for developers. So asking them to predict how to handle precision with different mixed units cuts against that goal, making the APIs much harder to use.
Currently LDML leaves the implementation open, but that provides too little guidance, and also limits the ability to provide test data in CLDR.
assess
Problem case
A programmer supplies an amount like 1.5254° degrees to a number formatter using unitPreferences. They also specify a certain precision (either a range of min/max decimal digits, or a range of min/max significant digits). For some locales, this turns into a mixed unit. The question is: how to apply the precision to the mixed units?
This can also happen with length (eg, 6 foot 2 inches), weight (3 lbs 9 oz), and other measures.
An implementation could apply the precision of a number formatter to the final unit. However, this mechanism has a couple of disadvantages, such as matching precision across user preferences. For example, suppose the input amount is 1.5254 and the precision is 2 decimals.
Locale A uses decimal degrees and gets 1.53°.
Locale B uses degrees, minutes, seconds, and gets 1° 31′ 31.44″
Locale B has far too precise a result compared to locales without mixed units: the equivalent of 1.52540 in precision, for 6 digits of accuracy instead of 3.
We could invent some special options for mixed units, but one of our primary goals is using unit preferences to handle the conversions and formatting for developers. So asking them to predict how to handle precision with different mixed units cuts against that goal, making the APIs much harder to use.
Currently LDML leaves the implementation open, but that provides too little guidance, and also limits the ability to provide test data in CLDR.
There is a draft design document at