Correct alternate calendar handling #109
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Expands
LocalesTest
to test a non-Gregorian calendar (Saudi Arabia uses an Islamic calendar) and to test with multiple device default locale calendars.The latter uncovered that we were converting from
java.time
types toCalendar
incorrectly, so I've fixed that bug. My understanding here was not correct: Rather than converting ISO-8601java.time
types to a locale-specificCalendar
instance, we want to convert them to an ISO-8601Calendar
instance, because that is what they represent. The device locale (or consumer-passed locale) should only be used during formatting: This is what theChronoLocalDate
docs mean when they say "This approach treats the problem of globalized calendar systems as a localization issue and confines it to the UI layer."Closes #107.