2017-08-15 174 views
2

虽然我练JSTL的timeZone标签,我试图运行这两个动作:JSTL时区(KST)执行错误发现

<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

我错过了什么或执行不正确? 我的错误实施案例,我应该联系谁?

回答

1

建议不要使用三个字母的时区ID。他们已被弃用。并不是所有的人都支持。

oracle java docs

三字母时区ID

为了与JDK 1.1.x的兼容,一些三字母时区 的ID(如 “PST”, “CTT”, “AST”)也被支持。但是,其 的使用已弃用,因为多个时区经常使用相同的缩写(例如,“CST”可能是美国“中央标准时间”和“中国标准时间”),然后Java平台可以使用 然后再使用 然后再使用 只认识其中之一。

2

GMT+09:00不是时区,这是一个UTC offset:差(以小时,分和秒)从UTC。它只是意味着“比UTC早9个小时”,并没有附加到任何特定地区或国家。 (但大多数系统通常将偏移量视为时区的“特殊类型”,仅为make things easier)。

KSTabbreviation for Korea Standard Time,但不是“真正的”时区。时区名称并非真正标准化,但许多系统使用IANA timezones names(始终采用格式Region/City,如Asia/SeoulEurope/London)。 系统通常会避免使用简写缩写(如CSTKST),因为它们是ambiguous and not standard

时区Asia/Seoul今天使用KST的缩写,但是过去也会使用Asia/Pyongyang。虽然,它们不是同一个区域。

时区是一个地区在其历史中具有和将会具有的所有不同偏移量的集合。今天Asia/Seoul使用+09:00偏移量,但Asia/Pyongyang也用于过去,所以它们的历史数据是不同的(这就是为什么它们是不同的区域)。

平壤有+08:30 offset until 1912,当改为+09:00。但在2015年它再次改变为+08:30,并将其用到今天。

首尔有一个different offset history:这也是在过去使用+08:30(50年代),日光节约时间(夏令时更改为+09:30),然后于1961年,今天改为+09:00,在一段时间了DST,以及仅使用+09:00而没有DST。

所有这些变化都是由政府和法律界定的,系统无法控制它。仅仅因为时区(一个区域)今天使用了一些偏移量,并不能保证它会永远使用它。 因此,尽管KST今天可以成为+09:00的“同义词”,但并不意味着它会永远如此。


所以,当你使用GMT+09:00,你只用偏移,没有任何关联到一个特定的时区(因为there are lots of timezones that can use this offset)。

在第二种情况下,似乎日期从KST(offfset +09:00)转换为UTC(偏移零或“GMT”)。请注意,第一种情况是偏移+09:00中的下午8点,第二种情况是UTC上午11点(偏移零或“GMT”),这是正确的。

也许JSTL不能识别KST(因为它的含糊性)并且使用UTC作为默认值。我会尝试用Asia/Seoul替换它,看看会发生什么。