Over what range of dates should the calendars of the existing java.util.Calendar and the LocalDate and ChronoLocalDate classes agree? Currently, LocalDate produces a different sequence of dates before 1582 due to different algorithms for computing leapYears. This affects not just Gregorian/ISO but also the other calendars. The correspondence between the old and the new APIs should be specified, documented and tested.
The ISO chronology is deliberately designed to be wrong for historical dates. While this can sound stupid, it is more sensible that choosing a single default cutover date from Julian to Gregorian. (Historically, there were many cutover dates, with the default simply being that of the Vatican. The British Empire was much later and Russia not until 1910 or so. And Sweden managed to get the cutover very wrong)
In my opinion, the provision of a historic/gregorian chronology (#47) is necessary for the JDK to handle alternate cutover dates.
Whether calendars like Minguo or Thai should use ISO or Gregorian is an open question. Using Gregorian runs into the same cutover date problems, which is why I propose ISO. As noted elsewhere, the Thai calendar was changed in 1940 anyway, and we aren't modelling that right now either.
Regardless of which variations get chosen, there is still a range of dates in which the chronology works correctly. The current range(YEAR) or range(EPOCH_DAY) method could provide that information. However, the current automatic checks in get() would turn any over/under into an exception which would be a harsh behavior.
An alternative would be to add a field to the range(field) that would return the oldest and newest range of EPOCH_DAYS supported and give developers a way to check if their actual dates are within the supported range.
I'm not sure what the use case for this is. All calendar systems are really only valid for a small range of dates.
Thus, I'd say "there is still a range of dates in which the chronology works correctly" is too optimistic.
So yes, more data could be added, but what and why? Pretty much all historical calendaring is a minefield, which is one reason why ISO is so important.
The original question is what is the range of dates to specify for each calendar for which the API works correctly.
It is sufficient to document and test that range and otherwise say the results are unspecified.
The API addition was just a suggestion.
The time-zone database only guarantees best-known information from 1970 onwards, so that is one option.
The next logical date would be something like 1945 (after the war), because its after the last change in Thailand and Russia. Then, something like 1900. Or specify calendar by calendar.
The spec gets to define what correctly means. I expect the ranges are Calendar by Calendar since they have been defined/amended at different times. One measure is that it and java.util.Calendar have the same results for the same operations; or that it matches JodaTime or that it matches the respective national standard.
OK, so go calendar by calendar. Define what each field means (most chronologies do that). And specify that it matches the "generally accepted form of the calendar system" (wikipedia link?). If necessary specify the earliest applicable date for that match. A comparison to j.u.Calendar may be useful, although not vital.
Created tests to compare with java.util.Calendar:
The current tests and ranges are adequate.