fuseau horaire JSTL (KST) Erreur de mise en œuvre a trouvé

Question

Bien que je pratique JSTL tag timeZone, j'ai essayé d'exécuter ces deux actions:

<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> 

Je crois qu'ils devraient produire même résultat. Cependant, ils produisent deux valeurs temporelles différentes.

2017 년 8 월 15 일 화요일 오후 (PM) 8 시 03 분 27 초 GMT + 09: 00

2017 년 8 월 15 일 화요일 오전 (AM) 11 시 03 분 27 초 GMT

Ai-je manqué quelque chose ou l'implémentation est incorrecte? En cas de mauvaise implémentation, qui dois-je contacter?

Answer 1

Il est déconseillé d'utiliser des ID de fuseau horaire à trois lettres. Ils sont obsolètes. Et tous ne sont pas soutenus.

Voir oracle java docs

trois lettres fuseau horaire ID

Pour la compatibilité avec JDK 1.1.x, un autre fuseau horaire de trois lettres ID (tels que "PST", "CTT", "AST") sont également supportés. Cependant, leur utilisation est obsolète car la même abréviation est souvent utilisée pour plusieurs fuseaux horaires (par exemple, "CST" pourrait être US "Central Standard Time" et "China Standard Time"), et la plate-forme Java peut alors seulement reconnaître l'un d'entre eux.

Answer 2

GMT+09:00 n'est pas un fuseau horaire, il est un UTC offset: une différence (en heures, minutes et secondes) de UTC. Cela signifie simplement "9 heures d'avance sur l'UTC", et ce n'est pas lié à une région ou à un pays en particulier. (la plupart des systèmes, cependant, traite généralement le décalage comme un "type spécial" de fuseau horaire, juste à make things easier).

KST est un abbreviation for Korea Standard Time, mais n'est pas un "vrai" fuseau horaire. Les noms de fuseaux horaires ne sont pas vraiment standardisés, mais de nombreux systèmes utilisent IANA timezones names (toujours au format Region/City, comme Asia/Seoul ou Europe/London). L'utilisation des abréviations courtes (comme CST ou KST) est généralement évitée par les systèmes car ils sont ambiguous and not standard.

Le fuseau horaire Asia/Seoul utilise l'abréviation KST aujourd'hui, mais il était également utilisé dans le passé par Asia/Pyongyang. Cependant, ils ne sont pas la même zone. Un fuseau horaire est un ensemble de décalages différents qu'une région a eu, a et aura au cours de son histoire. Aujourd'hui Asia/Seoul utilise le décalage +09:00, mais Asia/Pyongyang également utilisé dans le passé, donc leurs données historiques sont différentes (et c'est pourquoi ils sont des zones distinctes).

Pyongyang avait le +08:30 offset until 1912, lorsque modifié à +09:00. Mais en 2015, il a encore changé pour +08:30 et il l'utilise jusqu'à aujourd'hui.

Séoul a different offset history: il a également utilisé +08:30 dans le passé (dans les années 50), avec l'heure d'été (changement à +09:30 pendant l'été), puis en 1961 il changé +09:00, avait DST pendant un certain temps, et aujourd'hui utilise seulement +09:00 sans DST.

Tous ces changements sont définis par les gouvernements et les lois, et les systèmes n'ont aucun contrôle sur eux. Tout simplement parce qu'un fuseau horaire (une région) utilise un certain décalage aujourd'hui, il n'y a aucune garantie qu'il utilisera pour toujours. Donc, bien que KST puisse être un "synonyme" de +09:00 aujourd'hui, cela ne veut pas dire que ça sera comme ça pour toujours.

---

Ainsi, lorsque vous utilisez GMT+09:00, vous utilisez juste le décalage, sans aucune corrélation avec un fuseau horaire spécifique (parce there are lots of timezones that can use this offset).

Dans le second cas, il semble que la date est convertie de KST (offffset +09:00) en UTC (décalage zéro, ou "GMT"). Notez que le premier cas est 20 PM en décalage +09:00 et le second est 11 AM en UTC (décalage zéro, ou "GMT"), ce qui est correct.

Peut-être que JSTL ne peut pas reconnaître KST (en raison de son ambiguïté) et utilise UTC par défaut. Je vais essayer de le remplacer par Asia/Seoul et voir ce qui se passe.