A transition between two offsets caused by a discontinuity in the local time-line.

A transition between two offsets is normally the result of a daylight savings cutover.
The discontinuity is normally a gap in spring and an overlap in autumn.
ZoneOffsetTransition models the transition between the two offsets.

Gaps occur where there are local date-times that simply do not exist.
An example would be when the offset changes from +03:00 to +04:00.
This might be described as 'the clocks will move forward one hour tonight at 1am'.

Overlaps occur where there are local date-times that exist twice.
An example would be when the offset changes from +04:00 to +03:00.
This might be described as 'the clocks will move back one hour tonight at 2am'.

A rule expressing how to create a transition.

This class allows rules for identifying future transitions to be expressed.
A rule might be written in many forms:

the 16th March
the Sunday on or after the 16th March
the Sunday on or before the 16th March
the last Sunday in February

These different rule types can be expressed and queried.

The rules defining how the zone offset varies for a single time-zone.

The rules model all the historic and future transitions for a time-zone.
ZoneOffsetTransition is used for known transitions, typically historic.
ZoneOffsetTransitionRule is used for future transitions that are based
on the result of an algorithm.

The rules are loaded via ZoneRulesProvider using a ZoneId.
The same rules may be shared internally between multiple zone IDs.

Serializing an instance of ZoneRules will store the entire set of rules.
It does not store the zone ID as it is not part of the state of this object.

A rule implementation may or may not store full information about historic
and future transitions, and the information stored is only as accurate as
that supplied to the implementation by the rules provider.
Applications should treat the data provided as representing the best information
available to the implementation of this rule.

Thrown to indicate a problem with time-zone configuration.

This exception is used to indicate a problems with the configured
time-zone rules.

Provider of time-zone rules to the system.

This class manages the configuration of time-zone rules.
The static methods provide the public API that can be used to manage the providers.
The abstract methods provide the SPI that allows rules to be provided.

ZoneRulesProvider may be installed in an instance of the Java Platform as
extension classes, that is, jar files placed into any of the usual extension
directories. Installed providers are loaded using the service-provider loading
facility defined by the ServiceLoader class. A ZoneRulesProvider
identifies itself with a provider configuration file named
java.time.zone.ZoneRulesProvider in the resource directory
META-INF/services. The file should contain a line that specifies the
fully qualified concrete zonerules-provider class name.
Providers may also be made available by adding them to the class path or by
registering themselves via registerProvider(java.time.zone.ZoneRulesProvider) method.

The Java virtual machine has a default provider that provides zone rules
for the time-zones defined by IANA Time Zone Database (TZDB). If the system
property java.time.zone.DefaultZoneRulesProvider is defined then
it is taken to be the fully-qualified name of a concrete ZoneRulesProvider
class to be loaded as the default provider, using the system class loader.
If this system property is not defined, a system-default provider will be
loaded to serve as the default provider.

Rules are looked up primarily by zone ID, as used by ZoneId.
Only zone region IDs may be used, zone offset IDs are not used here.

Time-zone rules are political, thus the data can change at any time.
Each provider will provide the latest rules for each zone ID, but they
may also provide the history of how the rules changed.