¿Mi zona horaria BST tiene un retraso de una hora?

Question 1

BSTno se reconoce como nombre de zona horaria. Se utiliza como abreviatura en la salida, pero no se puede utilizar para designar una zona horaria. La mayoría de los programas no verifican los nombres de las zonas horarias y utilizan silenciosamente GMT si no se reconoce el nombre de la zona horaria.

Las abreviaturas como BST, CET, EST, etc. no siempre están bien definidas y a veces son ambiguas (¿es la hora estándar del este de América del Norte o de Australia?). Son significativos sólo en una región determinada, mientras que la configuración de zona horaria normalmente está destinada a su uso en todo el mundo. Además, una abreviatura como BST en realidad no designa una zona horaria, sino sólo la hora en que se encuentra en una determinada zona horaria durante parte del año (en Gran Bretaña, mientras está en vigor el horario de verano). Por lo tanto, se deben utilizar designaciones inequívocas, la mayoría de las cuales siguen el patrón continente/ciudad. En los sistemas Linux típicos, y creo que también en muchas otras variantes de Unix, puede ver qué abreviaturas están disponibles buscando en el directorio /usr/share/zoneinfo.

Entonces, en lugar de usar GMTen invierno y BSTen verano, use Europe/London.

Answer

BSTno se reconoce como nombre de zona horaria. Se utiliza como abreviatura en la salida, pero no se puede utilizar para designar una zona horaria. La mayoría de los programas no verifican los nombres de las zonas horarias y utilizan silenciosamente GMT si no se reconoce el nombre de la zona horaria.

Las abreviaturas como BST, CET, EST, etc. no siempre están bien definidas y a veces son ambiguas (¿es la hora estándar del este de América del Norte o de Australia?). Son significativos sólo en una región determinada, mientras que la configuración de zona horaria normalmente está destinada a su uso en todo el mundo. Además, una abreviatura como BST en realidad no designa una zona horaria, sino sólo la hora en que se encuentra en una determinada zona horaria durante parte del año (en Gran Bretaña, mientras está en vigor el horario de verano). Por lo tanto, se deben utilizar designaciones inequívocas, la mayoría de las cuales siguen el patrón continente/ciudad. En los sistemas Linux típicos, y creo que también en muchas otras variantes de Unix, puede ver qué abreviaturas están disponibles buscando en el directorio /usr/share/zoneinfo.

Entonces, en lugar de usar GMTen invierno y BSTen verano, use Europe/London.

Question 2

Como dijo @Gilles, BST es algo que se genera en date/ date +%Z, para decirles a los usuarios que es una fecha del horario de verano británico (es decir, GMT+1), no algo que defina una zona horaria, no es algo que pueda usar $TZ.

Ese BST es importante para los usuarios británicos. Cuando un usuario británico ve 14:00 BST, sabe que la marca de tiempo se refiere a las 14:00, hora de verano en Gran Bretaña continental (es decir, las 13:00 UTC). El uso de esos códigos de 3 a 4 letras está muy extendido en Gran Bretaña, EE. UU. y algunos otros países de habla inglesa, por lo que aparecen en la salida predeterminada de dateallí (en en_GB.UTF-8las configuraciones regionales, por ejemplo). Por otro lado, la mayoría de los usuarios franceses no tendrán idea de lo que 14:00 CESTsignifica (aunque CESTse refiere aHorario de verano de Europa Central, el GMT+2 que se aplica en verano en Francia), por lo que notarás que cuando las fechas especifican la zona horaria, prefieren incluir el desplazamiento UTC que CET/ CESTallí (como mardi 2 mai 2017, 13:34:09 (UTC+0200)).

La $TZvariable no debe contener esos códigos de 3 a 4 letras. Contiene algo quedefine/especificala zona horaria, la región en la que se encuentra. Las aplicaciones lo usan para conocer el desplazamiento con UTC en cualquier momento, cuándo cambiar entre el horario de invierno y verano y cuál se mostrará el código (si corresponde) para el horario de invierno y verano. al usuario (para aquellos usuarios para quienes es importante).

Para eso, puede configurar TZalguna especificación de zona horaria definida por el sistema. Me gusta TZ=:Europe/London(aunque muchos sistemas también lo aceptan TZ=Europe/London) o contiene TZlas reglas completas (aunque esas reglas son limitadas).

Por ejemplo, si lo uso TZ=:Europe/Londonen mi sistema, las reglas se leerán desde /usr/share/zoneinfo/Europe/London.

Ese archivo especificará, por ejemplo, que desde 1996, el desplazamiento de UTC es 0 desde el último domingo de octubre a las 2 a.m. UTC hasta el último domingo de marzo (con el nombre GMT para "hora media de Greenwich") y 1 en otro sentido (con el nombre BST para "British Summer Time"), mientras que desde 1970 (0 hora Unix) hasta 1972, fue 1 durante todo el año con el nombre BST para "British Summer Time".EstándarTiempo".

Ya puede ver que no tiene sentido utilizar BST como especificación de zona horaria. Primero, ha significado diferentes cosas en diferentes momentos, e incluso si solo consideramos la época actual, es solo un código para el horario de verano, por lo que no se puede utilizar como una especificación de zona horaria para todo el año.

Ahora también puedes TZcontener las reglas completas. Por ejemplo, para el "horario estándar británico (no de verano)" de principios de los años 70, puede utilizar la forma más sencilla de especificación:

TZ=BST-1

Eso especifica una zona horaria que siempre está a 1 hora al este de UTC y para la cual date +%Zsiempre devuelve BST. Esa zona horaria es correcta para Gran Bretaña continental a principios de los 70 y para el horario de verano desde 1972, pero no para el horario de invierno desde 1972 (y no podemos decirlo en el futuro).

O puede utilizar la especificación completa de las reglas actuales:

TZ=GMT0BST,M3.5.0/1:00:00,M10.5.0/2:00:00

Eso dice que hay dos períodos en el año, uno cuyo nombre es GMT con desplazamiento 0 y otro BST con desplazamiento 1 (implícito como 0+1 arriba cuando no se especifica), donde el cambio de uno a otro está activado. el último (5) domingo (0) de marzo (3) a las 1:00:00 UTC y nuevamente el último domingo de octubre a las 2:00.

Nuevamente, esa TZ funciona desde 1996 hasta ahora, pero no necesariamente de otra manera. Por ejemplo, para 1970-01-01 00:00:00 UTC (hora de la época 0 Unix, cuando la hora local era 1:00:00 BST (hora estándar británica) en Londres):

$ TZ=:Europe/London date -d @0
Thu  1 Jan 01:00:00 BST 1970
$ TZ=GMT0BST,M3.5.0/1:00:00,M10.5.0/2:00:00 date -d @0
Thu  1 Jan 00:00:00 GMT 1970

Por POSIX, el comportamiento de

TZ=BST-1está bien definido (como se describe arriba)
TZ=BST(o TZ=GMT/ TZ=UTC/ TZ=Europe/London) no está especificado.
TZ=:BST/ TZ=:Europe/Londonesimplementación definida. Es decir, los sistemas están destinados a respaldarlo y documentar lo que hace, aunque POSIX no nos dice qué se hace.

En el tercer caso anterior, en sistemas GNU (y creo que en la mayoría de los otros sistemas tipo Unix), cuando TZcomienza con :, lo que sigue se toma como una ruta a un archivo de definición de zona horaria. En el caso del sistema GNU, ese también es el caso cuando :se omite (incluso si el valor forma una especificación de zona horaria válida como UTC0, pero generalmente no deberían existir dichos archivos, aunque puedo ver algunas excepciones en mi sistema que lo convierten en un sistema que no es POSIX (por ejemplo, TZ=CST6CDT date -d 1943-01-01 +%Zsalidas CWTen lugar de CSTporque hay un /usr/share/zoneinfo/CST6CDTarchivo ¹ que define untiempo de guerrapara ese período)).

Esa ruta es generalmente una ruta relativa, en cuyo caso es relativa a $TZDIR(o alguna opción predeterminada, como /usr/share/zoneinfocuando $TZDIRno está configurada, como suele ser el caso). Por razones de seguridad, $TZDIRlas rutas absolutas o relativas con ..componentes se ignoran en contextos de escalada de privilegios (como en contextos setuid).

Por lo general, en un sistema GNU, un TZ=:BST, igual que TZ=BSTnormalmente buscará un /usr/share/zoneinfo/BSTarchivo. Si no se encuentra (como sería el caso, ya que BSTno es posible identificar una definición de zona horaria), normalmente asumirá la hora UTC y un nombre de zona horaria (como en date +%Zla salida) de BST.

¹ Aquellos CST6CDTcomo WET, CET, MET... son restos de otra época. A finales de 1993, la base de datos de TZ (como ahoramantenido por la IANA)cambiódesde el uso de nombres ad hoc (y con mayor frecuencia ambiguos) (como MET, GB-Eire, WET) hasta Area/Citydónde la ciudad es la ciudad más poblada (en el momento del lanzamiento) donde se aplica la zona (el área son áreas grandes como continente/océano). Para Gran Bretaña continental, donde solía usar GB-Eire(no WET), ahora (desde 1993) usa Europe/London. GB-Eire(como WET) todavía están disponibles para compatibilidad con versiones anteriores ( GB-Eireahora se vincula a Europe/London, mientras que WETse define como una zona que usa UTC en invierno y las reglas de la UE para el horario de verano (Gran Bretaña solo ha seguido las reglas de la UE desde 1996 y el Reino Unido ahora abandona la UE). nadie puede decir lo que depara el futuro)) pero no debería usarse ahora en nuevas implementaciones.

Answer