- Las zonas horarias son complejas, pero como las computadoras tienen que implementarlas, solo son raras dentro de un rango finito.
Asia/Kathmandutiene un offset inusual respecto a UTC.Africa/Casablancano encaja bien en el modelo de zonas horarias, así que está codificada de forma rígida.America/Nuukcomienza el horario de verano desde -01:00.Africa/CairoyAmerica/Santiagocomienzan el horario de verano a las 24:00 (no a las 00:00).Australia/Lord_Howetiene la regla de horario de verano más extraña.
PGXIIREAM: el papa Gregorio XIII lo controla todo
- La mayor parte del mundo usa un sistema de tiempo basado en el calendario gregoriano.
- El calendario gregoriano es muy útil para mantener la posición del sol consistente a lo largo del año.
- UTC es una formalización moderna del calendario gregoriano, y todo el mundo ajusta su hora con base en él.
Los segundos intercalares no importan
- La rotación de la Tierra se está desacelerando, así que se agregan segundos intercalares para compensarlo.
- Los segundos intercalares se pueden ignorar porque los lenguajes de programación no representan 61 segundos.
- Los proveedores de nube resuelven este problema haciendo que el reloj avance más lentamente durante un segundo intercalar.
Zonas horarias raras
Asia/Kathmandu tiene un offset inusual
- Nepal está 5 horas y 45 minutos por delante de UTC.
- Las computadoras pueden saber esto mediante la base de datos de zonas horarias de IANA.
Cadenas como PDT o CET no significan nada
- Los identificadores de zonas horarias pueden ser ambiguos, y muchas zonas horarias comparten el mismo identificador.
¿Cómo se representa una zona horaria con horario de verano?
- Las reglas de transición del horario de verano son complejas, y las computadoras calculan la hora local en función de ellas.
Africa/Casablanca y Asia/Gaza siguen la luna, pero las zonas horarias siguen al sol
- Marruecos y Gaza ajustan el horario de verano de acuerdo con el Ramadán, y esto está codificado de forma rígida.
America/Nuuk cambia al horario de verano a la -1:00
- Groenlandia comienza el horario de verano al mismo tiempo que Europa, pero en hora local empieza a la -1:00.
America/Santiago y Africa/Cairo cambian a las 24:00
- Estas zonas horarias cambian al horario de verano a las 24:00, lo que significa pasar al día siguiente.
Australia/Lord_Howe tiene la transición de horario de verano más rara
- La isla Lord Howe tiene una transición de horario de verano de 30 minutos.
Resumen de GN⁺
- Las zonas horarias son complejas, pero como las computadoras tienen que implementarlas, solo son raras dentro de un rango finito.
Australia/Lord_Howees la zona horaria más singular por su transición de horario de verano de 30 minutos.- Este artículo es útil para entender la complejidad de las zonas horarias y puede resultar interesante para programadores.
- Un proyecto con funcionalidad similar es
tzdb.
1 comentarios
Opiniones de Hacker News
La parte más interesante de la base de datos tz es que incluye una estimación del momento del Big Bang, y está diseñada para no calcular transiciones de zonas horarias que ocurran antes del Big Bang.
El mensaje del commit en https://github.com/eggert/tz/commit/b22d459a367f4d01b10f6f6b... también iba en el sentido de “no generemos timestamps anteriores al Big Bang, porque son físicamente sospechosos”, y poco después otro commit separado también prohibió los segundos intercalares anteriores al Big Bang.
datede Linux/Unix.Traía ejemplos de alrededor del siglo XV, con historias de que algún rey ordenó repetir cierta semana/mes porque le gustaba, o que otro rey eliminó cierta semana del calendario porque no le gustaba. Era una lectura bastante reveladora, pero ahora no la puedo encontrar.
Dicho de otro modo, la conclusión es: “los momentos anteriores al Big Bang están fuera del alcance de esta biblioteca, así que si algún algoritmo produce valores incorrectos solo antes del Big Bang, ese algoritmo es aceptable y no hace falta mejorarlo ni reemplazarlo”.
No parece que la utilidad justifique mucho los bugs potenciales, y la mayor parte de la complejidad sucia de tzdb está en
zic. A veces siento que habría sido mejor sizicno fuera un artefacto del que otras personas pudieran depender.Ojalá desaparezcan las zonas horarias en sí antes de que la teoría de zonas horarias quede obsoleta.
Para mí, la zona horaria más extraña es Africa/Addis_Ababa. Los propios habitantes de Etiopía en realidad no siguen ese método.
Localmente desplazan la hora 6 horas: el ciclo AM empieza al amanecer, es decir, a las 6:00 a. m., y el ciclo PM empieza al atardecer, a las 6:00 p. m.
https://en.wikipedia.org/wiki/Time_in_Ethiopia
Del mismo modo, el día termina a las 6:00 p. m., thenashara. Intuitivamente tiene mucho más sentido que el reloj angloparlante, y como está incorporado en el idioma, las confusiones de hora son raras.
https://en.wikipedia.org/wiki/Ethiopian_calendar
El calendario etíope consta de 12 meses de 30 días y de 5 o 6 días epagómenos que forman el decimotercer mes.
https://en.wikipedia.org/wiki/Roman_timekeeping
En el mundo angloparlante, antes el año también cambiaba el 25 de marzo: https://en.wikipedia.org/wiki/Calendar_(New_Style)_Act_1750#...
Técnicamente, ninguno de los dos es algo que tzdb pueda manejar. tzdb trata la hora civil, no calendarios ni otros sistemas de cálculo.
Lo raro de
Asia/Jerusalemse debe a que el horario de verano está muy ligado al tema de la separación entre religión y Estado. Las personas religiosas quieren que la jornada laboral sea conveniente para las festividades que empiezan al atardecer.Por eso, durante décadas, hasta mediados de los 2000, el horario de verano fue el resultado de una negociación anual entre partidos religiosos y seculares, y la decisión se tomaba apenas antes de la fecha de cambio, lo que causaba problemas con frecuencia.
Todavía incluye una excepción para que el horario de verano no termine en Rosh HaShanah, así que supongo que por eso las reglas futuras parecen complejas.
Si la UE finalmente logra abolirlo, tal vez lo sigan.
Por eso no quieren que el horario de verano haga todavía más tarde un evento que ya termina tarde. Además, en el día de ayuno de Yom Kippur querían que el ayuno terminara una hora antes. Al intentar ajustarse a esas fechas, el período de horario de verano quedaba demasiado corto y hacía falta negociar.
Decir que “los lenguajes de programación no pueden representar un minuto de 61 segundos” no es cierto. Alguien ya mencionó que Raku soporta segundos intercalares, y eso quizá sea en parte culpa mía
Es porque
DateTime.pm, la biblioteca de fecha/hora más popular de Perl 5, soporta segundos intercalares, y yo implementé ese soporte al crearDateTime.pmEn retrospectiva, casi con toda seguridad fue un error. A casi nadie le importan los segundos intercalares, y solo generan confusiones raras como “¿por qué sumar 60 segundos a veces no es lo mismo que sumar 1 minuto?”
En particular, el código se volvió mucho más complejo porque intentábamos validar si
second => 60era válido. El constructor recibe componentes de hora y una zona horaria arbitraria, así que para consultar la tabla de segundos intercalares hay que convertir a UTC, pero esa conversión en sí misma termina enredada con valores que incluyen segundos intercalares por razones históricasFue un desastre enorme para un beneficio minúsculo, y como la biblioteca estándar de fecha/hora de Raku parece haber tomado mucho de
DateTime.pmde Perl 5, creo que heredó parte de esas malas decisiones de diseñoMe da curiosidad cuál fue el proceso mental al principio. ¿Estaban demasiado metidos en el problema? Cuando uno está demasiado cerca de un problema y se concentra en él durante mucho tiempo, a veces pasa esto: gana el placer de arreglarlo antes de que se rompa
Se define más o menos como: “Instant es un momento específico medido en segundos atómicos y su parte fraccionaria, y no está vinculado a ningún epoch ni es aware de ninguno”
A principios de este año tuve que escribir una función que, dada una dirección de EE. UU., encontrara la hora local actual. El enfoque ingenuo sería mapear estáticamente el estado a una zona horaria, pero hay bastantes excepciones que impiden hacerlo así
En esa aplicación importaban el costo y la velocidad, así que compré por unos pocos dólares un CSV que mapeaba todos los ZIP code de EE. UU. a offsets UTC, si observan o no el horario de verano, etc.
Como
pytzrecibe nombres de zonas horarias de IANA, al final tuve que mapear manualmente la información de offset y horario de verano a una zona horaria específica, y por los territorios estadounidenses de ultramar y las bases militares también hicieron falta semánticas raras como las zonas horariasEtc[1] https://en.wikipedia.org/wiki/Tz_database#Area
El ZIP code probablemente también pueda ser suficiente, pero hay que tener cuidado. Si no hay demasiadas direcciones, un enfoque más robusto es hacer geocodificación inversa y luego usar una biblioteca que obtenga el identificador IANA a partir de los polígonos de límites de zonas horarias
https://github.com/RomanIakovlev/timeshape lo mantiene un excolega, y pudimos publicar como open source parte del trabajo que habíamos hecho internamente
Uno o dos sistemas marcaban los datos con hora local y los demás usaban UTC. Compré un viejo Farmers' Almanac para armar un algoritmo que manejara el horario de verano, pero al leer las reglas me desesperé
El calendario tenía reglas nominales para las transiciones, pero había una nota al pie que decía que, por intervenciones del Congreso, se habían ajustado año tras año y seguirían ajustándose. Le dije a mi jefe: “si pudiera escribir un algoritmo que predijera las votaciones futuras del Congreso, sería multimillonario y habría dejado este trabajo de ingeniería”
Creo que al final codifiqué las transiciones conocidas más recientes y las reglas nominales futuras. Era antes de que todo el mundo estuviera conectado a la red, y el código corría en computadoras independientes como VAX, así que no había muchas otras opciones
Combinar tres fuentes de datos de seguimiento, cada una con su propio estado de validez y degradación de calidad de medición, también fue una pesadilla, pero aun así fue más fácil que predecir las acciones futuras del Congreso
US/Eastern. Luego, si necesitas el offset UTC, aplicas esa zona horaria a la fecha correspondiente conpytzy obtienes el offsetLas zonas horarias con nombre son especiales porque son fijas. Las zonas horarias basadas en offset UTC como
-05:00o abreviaturas comoESTno son fijas para una ubicación determinada a lo largo del tiempo por el horario de veranoSi le preguntas a alguien su zona horaria y le das como opciones offsets o abreviaturas, todos terminan confundidos
Para la conversión latitud/longitud → zona horaria usé esta biblioteca de Python: https://github.com/jannikmi/timezonefinder
La fuente de datos también parecía bastante buena: https://github.com/evansiroky/timezone-boundary-builder/rele...
Etc. Sobre todo si pensabas exponer todos los identificadores tal cual a los usuariosEse archivo tiene un comentario que dice: “POSIX usa valores positivos al oeste de Greenwich, pero mucha gente espera que los valores positivos estén al este de Greenwich. Por ejemplo,
TZ='Etc/GMT+4'usa la abreviatura-04y está 4 horas detrás de UT, es decir, al oeste de Greenwich, pero mucha gente esperaría que estuviera 4 horas delante de UT, al este”La zona horaria de Palestina también es bastante rara
https://en.wikipedia.org/wiki/Time_in_the_State_of_Palestine
Tiene horario de verano, pero las fechas no son fijas; el gobierno anuncia cada año cuándo empieza y cuándo termina. A veces lo anuncia con menos de una semana de anticipación, así que inevitablemente surgen todo tipo de problemas interesantes
Las fechas de inicio y fin del horario de verano de Israel y Palestina no necesariamente coinciden
Creo que llamar “la zona horaria más rara” a un horario de verano con una diferencia de 30 minutos en vez de 1 hora pone la vara demasiado baja
Casi todo lo demás es más raro. Antarctica/Troll suena claramente más raro, y las zonas horarias de Marruecos y Gaza tienen reglas de otro tipo, al punto de que no se pueden expresar con los sistemas existentes. Las zonas horarias que cambian el día anterior a ciertas fechas, incluidas en la lista de bloqueo de Apple, también son lo bastante raras como para romper algo
Estoy de acuerdo con lo de los segundos intercalares. Más que conocimiento útil que un programador deba saber, es casi trivia. Las computadoras hacen smear de los segundos intercalares y ni siquiera saben cuándo ocurrieron. Se puede vivir olvidándose por completo de ellos
Dicho eso, hubo un cambio en el que los países pasaron de ignorar los segundos intercalares a tomarlos en cuenta, así que el cambio de hace unas décadas en Australia de
GMT+xaUTC+xfue una transición de ignorarlos a incluirlos. Que este hecho se ignore casi universalmente quizá sea algo buenoPero siempre me da un poco de risa que una organización grande diga “nuestros servidores tienen una precisión temporal de menos de un milisegundo gracias a la sincronización GPS y a una tarjeta PCIe de reloj atómico de rubidio desarrollada internamente”, y al mismo tiempo diga “los segundos intercalares se suavizan a lo largo de un día, así que en realidad no importa si la hora del servidor está desviada ±0,5 segundos”
[1] https://engineering.fb.com/2021/08/11/open-source/time-appli...
[2] https://engineering.fb.com/2020/03/18/production-engineering...
Por ejemplo, si el cielo está muy nublado, no se puede ver la luna sin importar dónde esté. Esto genera problemas al implementar calendarios para la administración de un país
Muchos países que adoptaron oficialmente el calendario islámico usan fechas aproximadas calculadas de antemano con base en la visibilidad esperada desde una ubicación específica. Por lo tanto, en realidad no hay un solo calendario islámico, sino más bien dos: el calendario islámico observado y el calendario predictivo, y ambos dependen del lugar donde se realiza la observación real o prevista
No sé cómo lo hacen Marruecos o Gaza
El detalle es que la hora de Noruega justamente usa horario de verano
Muchos mercados cerraron durante los segundos intercalares, y muchos bancos todavía detienen todas las transacciones durante los cambios de hora local para reducir el riesgo de errores
Incluso en aplicaciones a las que no les importa mucho, hubo una cantidad sorprendente de bugs relacionados con segundos intercalares, y hay buenas razones por las que la CGPM decidió abolirlos
https://en.wikipedia.org/wiki/Leap_second#Other_reported_sof...
Un excelente texto sobre las acrobacias del software de zonas horarias. De verdad es bastante flexible
Si todo son offsets finitos automatizados, no hay razón para que la política de horario de verano tenga que ajustarse a cambios de 60 minutos
¿No podría algún país decidir usar un offset que cambie continuamente durante todo el año? La tabla de búsqueda de offsets sería mucho más larga, pero esto también podría “resolver” el horario de verano. Como se ajustaría de a poquito todo el tiempo, no lo notaríamos, como con los segundos intercalares
Quienes dependen de relojes analógicos quizá ya no tendrían que ajustarlos siempre en la misma dirección
Un cambio de 10 minutos una vez al mes es mucho más fácil de asimilar, casi no se nota, y si te lo pierdes no es tan grave como quedar desfasado por 1 hora
Dejar de usar el horario de verano. Personalmente preferiría la hora estándar permanente antes que el horario de verano permanente, pero aceptaría cualquiera con tal de dejar de cambiar los relojes dos veces al año
Por supuesto, China es famosa por ser tan grande y aun así tener una sola zona horaria, lo que genera situaciones interesantes tanto interna como externamente
Una suposición realmente importante que no queda explícita en el formato de datos TZif es que, al pasar de hora local a hora UTC, como máximo hay dos posibilidades
Mucho software se apoya en esa suposición; por ejemplo,
java.time.LocalDateTimetienewithLaterOffsetAtOverlap(): https://docs.oracle.com/javase/8/docs/api/?java/time/LocalDa...Eso asume implícitamente que, cuando hay ambigüedad sobre qué significa las 2:30 a. m., las únicas soluciones posibles son las dos de antes y después del horario de verano. Si alguna zona horaria retrasa el reloj una vez a las 2:00 a. m. y otra vez a las 2:15 a. m., creando tres o más soluciones, muchas cosas no podrían representarlo
Lo que me gusta de la base de datos tz es que técnicamente es un diff de un diff
Almacena cómo cambió históricamente la diferencia entre cada zona horaria y UTC, así que puede verse como
diff^2. Pero la base de datos tz también recibe actualizaciones, así que esos commits son un diff del diff del diff, es decir,diff^3Se puede ir más lejos. Hay un registro de cambios y ese registro de cambios se guarda en git, así que un commit sobre el registro de cambios de tz es un cambio sobre una lista de cambios de una lista de cambios de una lista de cambios respecto de UTC:
diff^4Creo que el encuadre clave es que casi todas las fechas/horas son, en realidad, un conjunto de reglas de coincidencia bajo vigilancia
Puedes estimar cuántos segundos faltan para que se dispare una coincidencia, pero hasta que ocurra de verdad no puedes estar totalmente seguro, y en algunos casos quizá ni siquiera ocurra exactamente
La siguiente mitad del trabajo es convertir de vuelta la estimación delta de “parece que ocurrirá dentro de X segundos” a “parece que, en ese momento, el reloj de tu zona horaria mostrará Y”
No hay que olvidarse de seguir registrando qué zona horaria controla el evento y en qué zona horaria se muestra
[1] Las estimaciones UTC pueden desviarse hacia adelante o hacia atrás por la cantidad de segundos intercalares. TAI es más seguro, pero podría cambiar si alguien descubre algo nuevo e interesante que altere el comportamiento de los átomos de cesio
[0] Por ejemplo, un país podría desaparecer y con él su zona horaria. O un reloj podría saltar de 1:00 a 2:00, y por esa hora omitida el intervalo de 1:30 a 2:00 podría no ocurrir exactamente