当我练习JSTL时区标签时，我尝试运行以下两个操作：
<c:set var="now" value="<%= new java.util.Date() %>" />
<fmt:timeZone value="GMT+9:00">
<fmt:formatDate value="${now}" type="both"
dateStyle="full" timeStyle="full"/>
</fmt:timeZone>
<%-- and --%>
<fmt:timeZone value="KST">
<fmt:formatDate value="${now}" type="both"
dateStyle="full" timeStyle="full"/>
</fmt:timeZone>
我相信他们应该产生同样的结果。但是，它们生成以下两个不同的时间值。
2017년 8월 15일 화요일 오후(PM( 8시 03분 27초 GMT+09：00
2017년 8월 15일 화요일 오전(AM( 11시 03분 27초 GMT
我是否错过了某些内容或实现不正确？ 我遇到实施错误的情况，我应该联系谁？
GMT+09:00不是时区，而是UTC偏移量：与UTC的差异(以小时，分钟和秒为单位(。它只是意味着"比 UTC 早 9 小时"，并且不附加到任何特定地区或国家/地区。(不过，大多数系统通常将偏移量视为时区的"特殊类型"，只是为了让事情变得更容易(。
KST是韩国标准时间的缩写，但不是"真正的"时区。时区名称并没有真正标准化，但许多系统使用 IANA 时区名称(始终采用Region/City格式，如Asia/Seoul或Europe/London(。 系统通常避免使用简短的缩写(如CST或KST(，因为它们是模棱两可的，不是标准的。
时区Asia/Seoul今天使用KST缩写，但这在过去也被Asia/Pyongyang使用。虽然，它们不是同一个区域。
时区是一个区域在其历史上拥有、拥有和将要拥有的所有不同偏移量的集合。今天，Asia/Seoul使用+09:00偏移量，但过去也使用Asia/Pyongyang偏移量，因此它们的历史数据是不同的(这就是为什么它们是不同的区域(。
平壤的+08:30偏移量一直持续到1912年，当时改为+09:00。但在 2015 年，它再次更改为+08:30并且一直使用到今天。
首尔有不同的偏移历史：它在过去(50 年代(也使用+08:30，夏令时(夏季更改为+09:30(，然后在 1961 年改为+09:00，在一段时间内有 DST，今天只使用没有 DST 的+09:00。
所有这些变化都是由政府和法律定义的，系统无法控制它。仅仅因为一个时区(一个地区(今天使用了一些偏移量，并不能保证它会永远使用它。 因此，尽管KST可以成为今天+09:00的"同义词"，但这并不意味着它会永远这样。
因此，当您使用GMT+09:00时，您只使用偏移量，与特定时区没有任何关联(因为有很多时区可以使用此偏移量(。
在第二种情况下，日期似乎正在从KST(偏移量+09:00(转换为UTC(偏移量零或"GMT"(。请注意，第一种情况是偏移量+09:00中的 8 PM，第二种情况是 UTC 中的 11 AM(偏移量零或"GMT"(，这是正确的。
也许 JSTL 无法识别KST(因为它的歧义(并使用 UTC 作为默认值。我会尝试用Asia/Seoul替换它，看看会发生什么。
不建议使用三个字母的时区 ID。它们已弃用。并非所有方法都受支持。
查看 Oracle Java 文档
三个字母的时区 ID
为了与JDK 1.1.x兼容，其他一些三个字母的时区 还支持 ID(例如"PST"、"CTT"、"AST"(。然而，他们的 use已弃用，因为相同的缩写通常用于 多个时区(例如，"CST"可以是美国"中部" 标准时间"和"中国标准时间"(，Java平台可以 然后只识别其中之一。