Also fix ICU-12620 which is mark duplicate of ICU-9972 just now.
and fix ICU-22258.
Separate the new year and winter solstice cache since the calculated
value for these two calendar are mostly but not always the same due
to slightly different observation timeZone.
Remove the epochYear and zoneAstroCalc from the member data
and instead return them from a getStting() method with the two caches
since all four of them are constant per subclass of ChineseCalendar
and do not need to be different per object.
The known issues in the TestLimit is caused by both Calendar get/put the
value from the same cache while the calculated result depends on the
timeZone zoneAstroCalc.
Sometimes getVisibleIDs() method returns a null reference which might happend
because of inaccurate concurrent access. This change attempts to fix this
ICUServiceThreadTest flakiness.
substitution is using a DecimalFormat and its owning rule also has a modulus substitution. Took out a redundant
call to floor(). Added a hack to allow the caller to change the rounding behavior with setRoundingMode().
Added appropriate unit tests. Added additional documentation of the behavior to the API docs.
Change the logic of handling year in era 0 counting backwards
to depend on a boolean virtual function instead of adding
string comparsion code in the base class to have specific knowledge of
behavior of subclass.
Refactor different rules into implementation of private interface Algorithm.
Since IslamicCalendar is public in Java (not in C++), we cannot put them into different subclass of Calendar and have to let them use the same class and object since the caller UNFORTUNALLY can call setCalculationType and setCivil to change the object to different rule. With this refactoring, we group the formula for the same rule into the same Algorithm
implementaiton and now we only do the if/switch check in the constructor or during the call of setCalculationType and setCivil only. The calculation operation is then just delegate the work to the assigned concrete Algorithm.
Improve the efficency while the month is very large. Apply the same optimization in PR 2853 which estimate starting point of year iteration based on an inverse calculation.
ICU-22679 change parameter name
ICU-22679 Use Consumer
Test set+set, set+add, set+roll, add+add, roll+roll
Fix more int32_t overflow problems.
Optimize both Java and C++ Hebrew Calendar month/year advancement by first consider
every 235 months is 19 years before iteration.
