Consistent date time results vs java.util.Calendar #141

Closed
RogerRiggs opened this Issue Nov 8, 2012 · 9 comments

Projects

None yet

2 participants

@RogerRiggs
Collaborator

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.

@jodastephen
Member

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.

@RogerRiggs
Collaborator

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.

@jodastephen
Member

I'm not sure what the use case for this is. All calendar systems are really only valid for a small range of dates.

  • Our extrapolations into "before" eras is logical but unusual.
  • The Julian calendar system is only really valid from about 45 BC, and obviously, the year numbering changed later as well.
  • Thai Buddhist calendar is only accurate from 1941
  • Swedish calendar is Julian-Gregorian with multiple confused cutovers

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.

@RogerRiggs
Collaborator

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.

@jodastephen
Member

Define "correctly"...

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.

@RogerRiggs
Collaborator

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.

@jodastephen
Member

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.

@RogerRiggs
Collaborator

Created tests to compare with java.util.Calendar:

  • ISO from 1900 to 2100
  • Japanese from 1868 to 2100
  • ThaiBuddhist from 1583 to 2100
@RogerRiggs
Collaborator

The current tests and ranges are adequate.

@RogerRiggs RogerRiggs closed this Apr 1, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment