Time zones are geographical regions where the same rules for time apply. The rules are defined by governments and change frequently.
There are a number of sources of time zone information available, each represented by an instance of {@link ZoneRulesGroup}. One group is provided as standard - 'TZDB' - and more can be added.
Each group defines a naming scheme for the regions of the time zone. The format of the region is specific to the group. For example, the 'TZDB' group typically use the format {area}/{city}, such as 'Europe/London'.
Each group typically produces multiple versions of their data. The format of the version is specific to the group. For example, the 'TZDB' group use the format {year}{letter}, such as '2009b'.
In combination, a unique ID is created expressing the time-zone, formed from {groupID}:{regionID}#{versionID}.
The version can be set to an empty string. This represents the "floating version". The floating version will always choose the latest applicable set of rules. Applications will probably choose to use the floating version, as it guarantees usage of the latest rules.
In addition to the group/region/version combinations, TimeZone
can represent a fixed offset. This has an empty group and version ID. It is not possible to have an invalid instance of a fixed time zone.
The purpose of capturing all this information is to handle issues when manipulating and persisting time zones. For example, consider what happens if the government of a country changed the start or end of daylight savings time. If you created and stored a date using one version of the rules, and then load it up when a new version of the rules are in force, what should happen? The date might now be invalid, for example due to a gap in the local time-line. By storing the version of the time zone rules data together with the date, it is possible to tell that the rules have changed and to process accordingly.
TimeZone
merely represents the identifier of the zone. The actual rules are provided by {@link ZoneRules}. One difference is that serializing this class only stores the reference to the zone, whereas serializing ZoneRules
stores the entire set of rules.
After deserialization, or by using the special constructor, it is possible for the time zone to represent a group/region/version combination that is unavailable. Since this class can still be loaded even when the rules cannot, the application can continue. For example, a {@link ZonedDateTime} instance could still be queried.The application might also take appropriate corrective action. For example, an application might choose to download missing rules from a central server.
TimeZone is immutable and thread-safe. @author Stephen Colebourne
|
|
|
|
|
|