Shane F. Carr

> Another design would be to have methods to look this up, such as `get Intl.Locale.prototype.preferredCalendar`, which would get the calendar if present, and if absent get it from the...

How about, ```javascript navigator.locales[0].getLikelyCalendar() navigator.locales[0].getLikelyNumberingSystem() navigator.locales[0].getLikelyHourCycle() ``` where ```javascript Intl.Locale.prototype.getLikelyCalendar = function() { if (this.calendar) { return this.calendar; } else { // return best-guess calendar from locale data } }...

> @sffc I'm with you on semantics, but why `get` methods, and not getters, like `navigator.locales[0].likelyCalendar`? Also, I'm wondering whether we should call these methods/getters "likely" or "preferred" or something...

CC @FrankYFTang -- can you review this proposed change from @longlho and comment on whether it would impact implementations like V8?

This is shane from the ICU team. This is a known issue. Here's the upstream ticket: http://bugs.icu-project.org/trac/ticket/11318 I'm working on a major overhaul of the number formatting pipeline in ICU,...

FYI, ICU4C 61 now uses google/double-conversion to convert doubles into digits. It may resolve issues such as this one.

It should in principle be the same algorithm, because it's the same library as used in V8 and elsewhere. https://github.com/google/double-conversion

I seems counterintuitive to me that the spec insists on showing digits outside of the range supported by an IEEE double, which is only 15-17 significant digits. The double 1E21,...

If ICU really needs to support un-rounded doubles, that will need to be a feature added to ICU. However, I would like to first see a discussion on whether or...

1E21 cannot be stored exactly in a double. After 2^53, or ~9E15, not all integers are able to be expressed as doubles. If the specification needs to be changed, what...