Tarde o temprano, todo programador debe lidiar con los husos horarios
Y realmente no puedo ofrecer muchos consejos, pero si puedo entregar una advertencia
Puedo decirte por qué realmente nunca deberías lidiar con husos horarios si puedes evitarlo
Imaginemos que alguien ha hecho una aplicación
que te permite calcular hace cuántos segundos ha pasado algo
Escribes una fecha y una hora y te da el número de segundos.
Y lo miran y piensan "OK, esto funciona para mi..."
"Pero vamos a agregarle una pequeña opción que permita cambiar el huso horario"
Así, si estas comparando entre "ahora" en Nueva York y cinco días atrás en Londres, puedes hacer que funcione
Y está bien - el pequeño menú te permite cambiar la diferencia horaria entre Greenwich y tu ubicación.
Brillante.
Tarde o temprano, después de hacerse popular, reciben una llamada de Australia
Y Australia dirá "Buen día Ma'am--"
-- No voy a tratar de imitar acentos
Simplemente no debería imitar acentos
Australia dirá "¡Hola!"
"Por cierto, estamos 9 horas y media delante de Greenwich."
Y el programador dirá "¿en serio?"
"Sí, 9 horas y media"
"OK, voy a añadir un caso especial para ti. Está bien.
Más tarde, alguien llamará desde Nepal.
Y dirán "Hola, estamos 5 horas y un cuarto delante de Greenwich."
Y ellos dirán "¿en serio?" "Sí, ¡lo hemos estado por años! Sí, 5 horas y un cuarto"
Genial, Okay. Y pondrán un caso especial. Y quizá mirarán
la lista de husos horarios, la lista canónica que te dice
cómo es todo, y se asegurarán de haber cubierto cada huso horario en el mundo
Y entonces el otoño llegará.
Y recibirán una llamada de Inglaterra.
E Inglaterra dirá "Disculpen. Um, estamos una hora atrasados, ¿qué está pasando?"
"Oh, ¡el reloj acaba de cambiar!"
"Está bien - no, lidiamos con eso."
"Hicimos una nota de cuándo cambia el horario de verano para nosotros, ¡y ya lo incluimos!"
E Inglaterra dirá "No, mira, el horario de verano cambia una semana antes para nosotros."
"Es diferente dependiendo de dónde vives."
"También cambiamos nuestros relojes de vuelta una semana antes que ustedes."
Llegado este punto
generalmente el programador se pondrá las manos en la cabeza
y se dará cuenta en el lío que se ha metido
¡Y está bien! Lo incluirán
y se encargarán de cada país cambiando el horario de verano en un día diferente.
Verán el archivo que les dice cómo hacer eso y van a copiar en cada caso.
A continuación, van a recibir una llamada de alguien en el hemisferio sur otra vez, que va a decir
"No desplazamos el horario hacia atrás en el otoño, lo desplazamos hacia adelante."
"Nuestra primavera ... es en noviembre."
Y en ese momento, generalmente, van a empezar a mirar con ansia su bebida favorita
y se preguntarán si deberían tomar una copa rápida antes de ir seguir adelante ...
... E incluirán esto en el código también.
Entonces, van a recibir una llamada de Samoa.
En el Pacífico, en la línea internacional de cambio de fecha.
Y Samoa dirá "¡Hola!"
"Sí, nos saltamos un día al otro año."
Y el programador va a decir "¿qué?"
"Sí, nos saltamos un día. Fuimos del 29 de diciembre de 2011 al 31 de diciembre."
"Hemos cambiado de un lado de la línea internacional, de estar horas y horas detrás de Greenwich ...
... a estar horas y horas delante de Greenwich. Nos ayuda con el comercio con Australia ".
"¿Pueden tener en cuenta esto? ¿cuántos días tienen las cosas, y cuántos segundos están las cosas en el pasado"
[respirando profundamente] Está bien, hay un archivo que dice cuando un país ha cambiado su zona horaria.
Resulta que esto sucede con bastante frecuencia.
Pero lo anuncian con antelación, de manera que siempre que se mantenga actualizado el archivo
e incluyas eso en la lógica de tu programa, no habrá ningún problema.
Entonces miras hacia atrás y te das cuenta que durante la Segunda Guerra Mundial,
Inglaterra tenía el doble de horario de verano británico (BST)
Le agregaron una hora extra al BST
Así que estaba dos horas por delante de Greenwich, a pesar de... estar en Greenwich.
Está bien, lidias con eso
¿Notaron cómo empecé a hablar como si fuera tú o yo?
Porque ya he hecho esto antes y es muy, muy frustrante.
Y te aseguras de suscribirte a la lista
de cuándo los países van a cambiar sus zonas horarias - lo que sucede, al parecer, ¡demasiadas veces!
Incluso, a veces, varias veces en un año, porque los gobiernos cambian a lo largo del mismo.
Y entonces este programador mítico recibe una llamada de Libia;
que en 2013, con sólo un par de días de antelación, decidió que no iban a poner los relojes de nuevo luego del horario de verano.
Con tan poca antelación que no era posible para nadie actualizarse a tiempo
Lo que significa que todos los ordenadores de Libia, sin importar el sistema operativo en el que corrieran ...
... estaban una hora atrasados.
Eso está bien, apenas lees el artículo sobre eso y lo incluyes a toda prisa.
Y entonces, recibes una llamada de la Ribera Occidental.
Donde la población israelí está en una zona horaria diferente a la población palestina.
Debido a que una está siguiendo a Israel y la otra no.
Ahora tienes dos poblaciones de personas en el mismo lugar que están siguiendo diferentes husos horarios.
Y ahora están todos preguntándose que qué huso horario utilizan, dependiendo de quiénes son y dónde están
¡Y no hay manera de incluir eso en el programa! Y entonces...
Entonces recibes una llamada de un historiador.
Quien dice "bien, estoy tratando de calcular fechas del siglo 18".
"Y cambiamos del calendario juliano al calendario gregoriano."
"No es que hayamos perdido cerca de tres semanas ...
... es sólo que nos saltamos desde esta fecha a esta fecha, y perdimos las otras ".
"¿Pueden incluir esto de forma funcione para mí?"
Está bien porque alguien ya te dijo cuáles son esas fechas
y puedes incluir esto la lógica de tu programa
pero ahora se ve realmente largo y realmente complicado
y es una maraña de código espagueti que de alguna manera funciona
¡y entonces recibes una llamada de un historiador ruso!
Quien dice: "Sí, sólo cambiamos el calendario gregoriano en el siglo 20 ...
... y resulta que la fecha que has saltado depende en función de la ubicación ...
... podrías lidiar con esto también?" ¡Y entonces recibes otra llamada del historiador británico!
¡Quien dice que hasta, creo que fue el siglo 16...
el año comenzó el 25 de marzo!
Sólo para volarte la cabeza ahí mismo
Desde el 24 de marzo de 924
y entonces sería 25 de marzo de 925. Y ese es el día siguiente.
¡Porque has pasado del 31 de diciembre de 924, hasta el 1 de enero de 924, ya que va en ese orden!
Es masivamente complicado, Y ENTONCES...
recibes la llamada de un astrofísico ...
Quien dice que "Por cierto, ¡acabamos de tener un segundo adicional!"
Y en este punto, ya sólo puedes decir "¡¿...qué?!"
Segundo adicional; porque la Tierra no gira a velocidad constante.
Se ralentiza, se acelera, sus placas tectónicas se mueven
los campos magnéticos cambian, o algo por el estilo. Y así, de vez en cuando
la Unión Astronómica Internacional decidirá si necesitamos un segundo adicional
Si lo hace, los relojes van de 23:59:58
a 23:59:59
y entonces en vez de ser [00:00:00] como cualquier zona horaria sensata
va a 23:59:60!
¡Y todo se rompe porque de repente tienes 61 segundos en un minuto!
Así que dependiendo de tu implementación
... o tu reloj se sale un segundo de sincronización con el resto del mundo...
... o repite un segundo.
La forma en la que debes manejar esto es con algo que se llama "Unix Timestamp".
Y creo que Numberphile, ha hablado de esto antes.
Tienes este número que se inició en el primer segundo exacto de 1970
e incrementa un segundo, por segundo.
Constantemente. Tic, tic, tic.
Y esto es excelente porque lo que debes hacer a hacer es tomar cualquier fecha que se te haya dado
y la calculas como una "Unix Timestamp",
y pones esto en tu base de datos.
Y eso lidiará con los segundos adicionales
¡EXCEPTO QUE NO LO HACE! ¡Claro que no lo hace!
¡Porque tienes el Tiempo Universal Coordinado
que incluye segundos adicionales!
Se repite de vez en cuando, y sólo incluye 23:59:60
y entonces tienes el tiempo astronómico! Que no incluye saltos de segundos
y ha estado constantemente fuera de sincronía con el resto del mundo
porque tenemos que mirar las estrellas y diseñar telescopios basados en ello!
[suspiro profundo]
Y lo que aprendes...
Lo que aprendes después de tratar con zonas horarias, es que lo que haces ...
...es poner bien lejos tu código...
...no intentas escribir nada para lidiar con esto.
Te fijas en las personas que han estado haciendo lo mismo antes que tú.
Te fijas en las primeras personas, las personas que se han ocupado de esto antes,
las personas que han construido el código espagueti,
y les agradeces por hacerlo de código abierto,
y les das crédito, y tomas lo que han hecho y lo pones en tu programa,
y nunca jamás lo miras de nuevo.
Porque de esta forma yace la locura.
Google tiene un muy, muy buen enfoque para saltar segundos que se inventaron ellos mismos.
Hay un artículo sobre esto en su blog, creo, que lo explica bien.
Hacen algo llamado un "difamación adicional".
Debido a que tener 61 segundos en un minuto,
o porque tener un reloj que vuelva a marcar el mismo segundo,
puede ser muy, muy malo para las grandes compañias que tienen que
sincronizar todo muy precisamente y tienen que confiar en que un bit de datos se almacenó antes de que otro,
esencialmente aumentan el segundo a lo largo de todo el día.
Aumentan su reloj por un microsegundo a la vez.
Tic tIc tic, a través de todo el día.
Por lo que a veces está medio segundo fuera de la realidad,
pero siempre y cuando todo en sus servidores esté la mitad de un segundo fuera.
Está construido para estar fuera de sincronía con el mundo, siempre y cuando se sepa que una cosa ocurrió antes de otra.
Tener continuidad es más importante que que tener la hora exacta. Subtitulado por: Javier Goldschmidt y Luis A. Martínez