André Bargull

Can this PR get merged, so I can prepare some follow-up changes to update tests to allow alternative era strings? Thanks!

> Note that @ptomato is out on vacation this week. The PR is already approved, it just needs someone with commit access to merge the changes.

FWIW: This issue is also filed at .

Still reproduces with release 1.5, except that the assertions are changed: Chinese/Dangi: ``` calendrical_calculations-0.1.1/src/chinese_based.rs:571:9: assertion failed: diff == 29 || diff == 30 ``` IslamicObservational: ``` calendrical_calculations-0.1.1/src/islamic.rs:92:21: (ObservationalIslamic) Found year...

The assertion [Year offset too big to store](https://github.com/unicode-org/icu4x/blob/7634c7e8a0c9cf1bf0f47d9f75588e5ddd73873d/components/calendar/src/provider/chinese_based.rs#L163) can also be triggered when using years too far into the future or past: ```rs let cal = Chinese::new_always_calculating(); let era =...

Do we want/need to make a clearer distinction between resolving links to zones and actual time zone transition data? For example ICU doesn't provide any time zone transition data for...

> The recommendation was written to give implementers (or ICU!) leeway to choose alternate ways to build TZDB as long as there's at least one Zone per country. Do you...

I guess it's okay to add some sort of waiting period. Implementation-wise there are some issues I still have to think about, but those shouldn't matter for this proposal: -...

ECMA-262 sorts built-in properties alphabetically, with Symbol-keyed properties being sorted to the end. Does it make sense to follow in ECMA-402?

Implementations most likely call into `std::sqrt`, which computes the exact result. (`std::sqrt` is required to compute the exact result to be IEEE-754 compliant.)