java.time.ZoneId 是java8的新时区类

据说是新标准, 等同GMT+8 , 可能取代GMT+8 ? 一个+8 一个-8 😶

用"8:00"会报错

重庆1

重庆2

香港1

香港2

UTC : 世界协调时

GMT : 格林威治平时 不是格林威治本地时 , 格林尼治本地的时间是GMT+1

UTC与GMT目前相差小于0.9秒(理论上) 受天体运动影响

UTC更精准(使用了原子钟)

我的理解是,GMT是时区,UTC不是时区,是一个基准,只是他们表示的时间近乎相同

ZoneId用于标识用于在Instant和LocalDateTime之间进行转换的规则。ID有两种不同的类型： •固定的偏移量-相对于UTC /格林威治标准时间的完全解析的偏移量，它对所有本地日期时间都使用相同的偏移量 •地理区域-适用于查找与UTC /格林威治的偏移量的一组特定规则的区域 大多数固定偏移量由ZoneOffset表示。在任何ZoneId上调用normalized（）将确保将固定的偏移量ID表示为ZoneOffset。 ZoneRules定义了描述偏移量何时更改以及如何更改的实际规则。此类仅是用于获取基础规则的ID。之所以采用这种方法，是因为规则是由政府定义且频繁更改的，而该ID是稳定的。

区别还有其他影响。序列化ZoneId仅将发送ID，而序列化规则将发送整个数据集。类似地，两个ID的比较仅检查ID，而两个规则的比较则检查整个数据集。

时区ID 该ID在系统内是唯一的.ID有三种类型。 最简单的ID类型是ZoneOffset中的ID，它由’Z’和以’+‘或’-'开头的ID组成。

下一类ID是带有某种形式的前缀的偏移样式ID，例如’GMT + 2’或’UTC + 01：00’。可识别的前缀为’UTC’，‘GMT’和’UT’。是后缀，将在创建过程中进行规范化。可以使用normalized（）将这些ID规范化为ZoneOffset。

ID的第三种类型是基于区域的ID。基于区域的ID必须包含两个或多个字符，并且不能以’UTC’，‘GMT’，‘UT’，’+‘或’-'开头。基于区域的ID由配置定义，请参见ZoneRulesProvider。提供从ID到底层ZoneRules的查找。

时区规则由政府定义并经常更改。有许多组织（在此称为组）来监视时区更改并进行整理。默认组是IANA时区数据库（TZDB）。其他组织包括IATA （航空业团体）和Microsoft。

每个组为其提供的区域ID定义其自己的格式.TZDB组定义诸如欧洲/伦敦’‘或美国/纽约’'的ID.TZDB ID优先于其他组。

强烈建议将组名包括在TZDB以外的其他组提供的所有ID中，以免发生冲突。例如，国际航空运输协会（IATA）航空公司的时区区域ID通常与三个字母的机场代码相同，但是乌得勒支机场的代码为’UTC’，这显然是冲突的.TZDB以外的其他组的区域ID的推荐格式是’group〜region’。因此，如果定义了IATA数据，乌得勒支机场将是’IATA〜UTC’。

序列化 此类可以序列化并以外部格式存储字符串区域ID。ZoneOffset子类使用专用格式，该格式仅存储UTC /格林威治的偏移量。 可以在ID不明的Java运行时中反序列化ZoneId。例如，如果服务器端Java运行时已使用新的区域ID更新，但客户端Java运行时尚未更新。在这种情况下，ZoneId对象将存在，并且可以使用getId，equals，hashCode，toString，getDisplayName和normalized进行查询。但是，对getRules的任何调用都将失败并显示ZoneRulesException。此方法旨在允许加载和查询ZonedDateTime，但在具有不完整时区信息的Java Runtime上未进行修改。

这是一个基于值的类；在ZoneId实例上使用标识敏感的操作（包括引用等于（==），标识哈希码或同步）可能会产生不可预测的结果，应避免使用equals方法进行比较。

* A {@code ZoneId} is used to identify the rules used to convert between * an {@link Instant} and a {@link LocalDateTime}. * There are two distinct types of ID: * * Fixed offsets - a fully resolved offset from UTC/Greenwich, that uses * the same offset for all local date-times * Geographical regions - an area where a specific set of rules for finding * the offset from UTC/Greenwich apply * * Most fixed offsets are represented by {@link ZoneOffset}. * Calling {@link #normalized()} on any {@code ZoneId} will ensure that a * fixed offset ID will be represented as a {@code ZoneOffset}. *

* The actual rules, describing when and how the offset changes, are defined by {@link ZoneRules}. * This class is simply an ID used to obtain the underlying rules. * This approach is taken because rules are defined by governments and change * frequently, whereas the ID is stable. *

* The distinction has other effects. Serializing the {@code ZoneId} will only send * the ID, whereas serializing the rules sends the entire data set. * Similarly, a comparison of two IDs only examines the ID, whereas * a comparison of two rules examines the entire data set. * * Time-zone IDs * The ID is unique within the system. * There are three types of ID. *

* The simplest type of ID is that from {@code ZoneOffset}. * This consists of 'Z' and IDs starting with '+' or '-'. *

* The next type of ID are offset-style IDs with some form of prefix, * such as 'GMT+2' or 'UTC+01:00'. * The recognised prefixes are 'UTC', 'GMT' and 'UT'. * The offset is the suffix and will be normalized during creation. * These IDs can be normalized to a {@code ZoneOffset} using {@code normalized()}. *

* The third type of ID are region-based IDs. A region-based ID must be of * two or more characters, and not start with 'UTC', 'GMT', 'UT' '+' or '-'. * Region-based IDs are defined by configuration, see {@link ZoneRulesProvider}. * The configuration focuses on providing the lookup from the ID to the * underlying {@code ZoneRules}. *

* Time-zone rules are defined by governments and change frequently. * There are a number of organizations, known here as groups, that monitor * time-zone changes and collate them. * The default group is the IANA Time Zone Database (TZDB). * Other organizations include IATA (the airline industry body) and Microsoft. *

* Each group defines its own format for the region ID it provides. * The TZDB group defines IDs such as 'Europe/London' or 'America/New_York'. * TZDB IDs take precedence over other groups. *

* It is strongly recommended that the group name is included in all IDs supplied by * groups other than TZDB to avoid conflicts. For example, IATA airline time-zone * region IDs are typically the same as the three letter airport code. * However, the airport of Utrecht has the code 'UTC', which is obviously a conflict. * The recommended format for region IDs from groups other than TZDB is 'group~region'. * Thus if IATA data were defined, Utrecht airport would be 'IATA~UTC'. * * Serialization * This class can be serialized and stores the string zone ID in the external form. * The {@code ZoneOffset} subclass uses a dedicated format that only stores the * offset from UTC/Greenwich. *

* A {@code ZoneId} can be deserialized in a Java Runtime where the ID is unknown. * For example, if a server-side Java Runtime has been updated with a new zone ID, but * the client-side Java Runtime has not been updated. In this case, the {@code ZoneId} * object will exist, and can be queried using {@code getId}, {@code equals}, * {@code hashCode}, {@code toString}, {@code getDisplayName} and {@code normalized}. * However, any call to {@code getRules} will fail with {@code ZoneRulesException}. * This approach is designed to allow a {@link ZonedDateTime} to be loaded and * queried, but not modified, on a Java Runtime with incomplete time-zone information. * *

* This is a value-based * class; use of identity-sensitive operations (including reference equality * ({@code ==}), identity hash code, or synchronization) on instances of * {@code ZoneId} may have unpredictable results and should be avoided. * The {@code equals} method should be used for comparisons. * * @implSpec * This abstract class has two implementations, both of which are immutable and thread-safe. * One implementation models region-based IDs, the other is {@code ZoneOffset} modelling * offset-based IDs. This difference is visible in serialization. * * @since 1.8 */ public abstract class ZoneId implements Serializable { 从这里可以看出 CTT 代表上海时区的简写

区域覆盖图可启用短时区名称。 短区域ID的使用已在java.util.TimeZone中弃用。加粗样式此映射允许通过of（String，Map）工厂方法继续使用这些ID。 此映射包含与TZDB 2005r和更高版本一致的ID的映射，其中“ EST”，“ MST”和“ HST”映射到不包括夏时制的ID。

* Use of short zone IDs has been deprecated in {@code java.util.TimeZone}. * This map allows the IDs to continue to be used via the * {@link #of(String, Map)} factory method. *

* This map contains a mapping of the IDs that is in line with TZDB 2005r and * later, where 'EST', 'MST' and 'HST' map to IDs which do not include daylight savings. * */ public static final Map SHORT_IDS = Map.ofEntries( entry("ACT", "Australia/Darwin"), entry("AET", "Australia/Sydney"), entry("AGT", "America/Argentina/Buenos_Aires"), entry("ART", "Africa/Cairo"), entry("AST", "America/Anchorage"), entry("BET", "America/Sao_Paulo"), entry("BST", "Asia/Dhaka"), entry("CAT", "Africa/Harare"), entry("CNT", "America/St_Johns"), entry("CST", "America/Chicago"), entry("CTT", "Asia/Shanghai"), entry("EAT", "Africa/Addis_Ababa"), entry("ECT", "Europe/Paris"), entry("IET", "America/Indiana/Indianapolis"), entry("IST", "Asia/Kolkata"), entry("JST", "Asia/Tokyo"), entry("MIT", "Pacific/Apia"), entry("NET", "Asia/Yerevan"), entry("NST", "Pacific/Auckland"), entry("PLT", "Asia/Karachi"), entry("PNT", "America/Phoenix"), entry("PRT", "America/Puerto_Rico"), entry("PST", "America/Los_Angeles"), entry("SST", "Pacific/Guadalcanal"), entry("VST", "Asia/Ho_Chi_Minh"), entry("EST", "-05:00"), entry("MST", "-07:00"), entry("HST", "-10:00") ); ZoneId的公有静态方法 ZoneId.systemDefault() public static ZoneId systemDefault() { return TimeZone.getDefault().toZoneId(); } ZoneId.of

ZoneId of(String zoneId, Map aliasMap)

ZoneId of(String zoneId)

ZoneId ofOffset(String prefix, ZoneOffset offset)

ZoneId of(String zoneId, boolean checkAvailable)