Currently, Period is defined to be "years, months and days" where the meaning of that only happens when the class is added to a date. This definition is pragmatic, but also pretty icky. It means that a period between two ISO dates can be added to a Hijrah date, an action which isn't meaningful.

An alternative design would be to create a ChronoPeriod interface with a subset of methods from Period, plus a getChronology() method. Period would implement ChronoPeriod and be the ISO implementation (just like ChronoLocalDate and LocalDate). A private implementation would handle all non-ISO calendar systems, just like ChronoLocalDateImpl.

With this change, all periods would be chronology specific. Runtime exceptions would prevent a Hijrah-date derived period from being added to an ISO date.

This requires adding one public interface and one private class to the API, both in the chrono package.

The change is relatively low risk. It increases runtime safety and is a relatively logical change, since all references to years/months/days should have a related calendar system. However, it does make it harder to transfer periods between two related calendar systems, such as the Japanese, Thai and ISO.

See Github issue #331; https://github.com/ThreeTen/threeten/issues/331