7 mitos sobre tiempo y horas que muchos programadores se creen (y que son mentira)
Menú de navegaciónMenú
Categorías

La mejor forma de Aprender Programación online y en español www.campusmvp.es

?id=0456df96-ced6-4343-9ada-aaa2319a117e

7 mitos sobre tiempo y horas que muchos programadores se creen (y que son mentira)

campusMVP - La mejor formación online para desarrolladores como tú

Imagen ornamental, manos de mujer sujetando un globo terráqueo sobre un fondo de papel de periódico
Fotografía de dominio público

Una de las cosas más habituales que hay que hacer en cualquier aplicación es gestionar datos relativos a fechas y horas. Esto es así independientemente de si se trata de aplicaciones web, de gestión, para escritorio, apps móviles... y tampoco depende del lenguaje de programación que utilicemos: Java, .NET, JavaScript, Python... todos tienen bibliotecas para gestionar datos relativos a fechas y horas.

Sin embargo, existen muchos pequeños detalles que debemos tener en cuenta cuando manejamos datos de este tipo en nuestro código. Muchos de estos detalles se nos escapan a veces o directamente puede que no los conozcamos.

Vamos a repasar a continuación algunos mitos y falsedades sobre el tiempo y las horas que muchos programadores desconocen pero que deberían saber. Puede que algunos los tengas claros, pero seguro que otros te sorprenden. Además, es posible que no tengas que lidiar con ellos nunca porque tu lenguaje favorito (o el sistema operativo) se ocupará de los detalles, pero cuando sobrevenga un problema grave te alegrarás de conocer algunas de estas curiosidades, pues te podrá ayudar a determinar qué puede estar pasando.

¡Vamos a ello!

MITO 1.- Todos los días tienen 24 horas

No es cierto al menos dos veces al año: en el hemisferio norte, en octubre durante el cambio de horario de verano a invierno (se atrasa una hora) el día tiene 25 horas. En marzo, cuando se vuelve a pasar al horario de verano, el reloj se adelanta y el día dura solo 23 horas. Esto es necesario tenerlo controlado a la hora de restar fechas y horas puesto que si para nuestra aplicación es importante la precisión hasta el nivel de 1 hora, podríamos tener problemas.

MITO 2.- El horario de verano va desde primavera a otoño

En general sí, pero no en Marruecos. En este país se suspende el horario de verano mientras dura el Ramadán, la época de ayuno y meditación de los musulmanes, que además cada año cae en una fecha diferente según el calendario lunar. Por ejemplo, en 2017 el Ramadán fue entre el 21 de mayo y el 2 de julio, y a las 3 de la mañana de esos días se vuelve al horario de invierno y verano respectivamente. Este año 2018 el horario de invierno se retomará el 13 de mayo y se volverá al de verano el 17 de junio.

MITO 3.- Todas las horas tienen 3600 segundos (60 min x 60 segundos)

No siempre. Por ejemplo, la última hora del día 30 de junio de 2015 tuvo 1 segundo de más. El motivo de estas anomalías es la inclusión de un "segundo bisiesto" para compensar los efectos de la ralentización de la rotación de la tierra sobre la hora solar. Es un tema muy interesante del que ya te hablamos con detalle en aquella ocasión. El caso es que es otra cosa que debes saber y tener en cuenta en tus cálculos.

MITO 4.- GMT y UTC son lo mismo

Casi, pero no...

GMT son las siglas de Greenwich Mean Time y se refiere a la hora solar en el meridiano que pasa por la localidad británica de Greenwich, en lo que se dio en llamar la longitud 0. En GMT se mide el día en función de la rotación de la tierra, y se dividen las zonas horarias a partir de este meridiano. Durante muchos años la diferencia horaria se expresó en unidades positivas y negativas respecto a la hora en Greenwich, o sea, respecto a GMT.

UTC son las siglas de Universal Time Coordinated y es un sistema de medición del tiempo. Se basa en la definición de la unidad de tiempo "segundo" en el sistema internacional y por lo tanto no depende de la velocidad de rotación de la tierra (que además es variable). UTC es lo que se utiliza en la actualidad (desde 1967) para medir el tiempo en todo el mundo, manteniendo coordinados diversos relojes atómicos (de ahí su nombre) para tener una referencia común.

El tiempo UTC se determina a través de dos componentes:

  • El Tiempo Atómico Internacional o TAI, que coordina a 400 relojes atómicos en todo el mundo y determina la forma en la que deben marcar el tiempo los demás relojes.
  • El Tiempo Universal o UT, que compara el ritmo de los dispositivos anteriores con la rotación de la tierra, es decir, con la duración real del día.

Este último componente se ajusta de vez en cuando para que el tiempo UTC coincida con el día solar, ya que la tierra se decelera poco a poco de manera imperceptible a medida que pasa el tiempo. Es por eso que se introducen los "segundos bisiestos" (que hemos visto antes) cada cierto número de años. En realidad la diferencia entre la duración real del día y la duración según UTC no puede ser mayor de 0,9 segundos, de ahí que se introduzca ese segundo bisiesto cuando es necesario.

Aunque en la práctica son casi intercambiables y podemos hablar tanto de tiempo GMT como UTC, la forma correcta de referirnos al tiempo indicando la zona horaria es con UTC. Así, por ejemplo, en España estamos ubicados en invierno en UTC+1 o UTC+1:00 (ambas formas son correctas). Aunque si decimos que estamos en GMT+1 todo el mundo nos entenderá. Pero a la hora de programar las fechas se refieren siempre en formato UTC, ya que GMT hoy en día es simplemente la zona horaria en la que se encuentra Inglaterra y se denomina así por razones históricas.

MITO 5.- Todos los países cambian a horario de verano e invierno al mismo tiempo

En absoluto.

Existen algunas semanas de diferencia entre las fechas de cambio de horario de verano e invierno entre los diversos países que lo observan. Por ejemplo, en 2018 el horario de verano entrará en España el 25 de marzo, pero en EEUU lo habrá hecho el 11 de marzo, dos semanas antes. Por ello, durante ese periodo, las diferencias horarias entre esos países serán menores que las que habrá a partir del 25 de marzo.

En una gran mayoría de países del hemisferio sur no se observa el horario de verano, por lo que la hora no cambia en todo el año (por ejemplo, en casi toda Hispanoamérica). Pero en los países de este hemisferio que sí cambian el horario, dicho cambio ocurre justo al contrario que en el hemisferio norte: pasan a horario de verano en octubre o noviembre y vuelven al de invierno en febrero o marzo, ya que las estaciones están invertidas (cuando aquí en Europa es verano, es invierno en Argentina, por ejemplo).

La cosa se complica aún más: en algunos países, según la región en la que estemos, se observará o no el horario de verano/invierno. Por ejemplo en Sao Paulo, Brasil, sí se cambia de horario (al revés que en el hemisferio norte, eso sí) pero no en Brasilia, la capital de dicho país, que al igual que otras zonas del mismo no siguen el horario de verano/invierno y no cambian su hora nunca 😵

MITO 6.- Las zonas horarias se miden en incrementos o decrementos de 1 hora desde GMT

Por ejemplo, en España estamos ahora mismo en UTC+1 (horario de invierno) y en Colombia están en UTC-5 (6 horas de diferencia). La mayor parte de las veces veremos que las diferencias son así: números enteros.

Sin embargo existen ciertos países, o peor, ciertas zonas de algunos países, en los que la diferencia horaria con UTC es una fracción de hora.

Por ejemplo, India está en UTC +5:30, es decir, cinco horas y media sobre UTC. Corea del Norte a UTC+8:30, Y ciertas zonas de Australia tienen incluida media hora de diferencia horaria: UTC+9:30 en Adelaida o UTC+10:30 en las Coco Islands (las islas famosas por el dominio de internet .cc, que además en verano están ¡a UTC+11:00!), por citar solo un par de ejemplos dentro del país/continente, en donde hay muchas más zonas todavía.

Pero no se acaba la cosa aquí: Nepal está ubicada en UTC+5:45 y algunas islas de Nueva Zelanda ¡¡están en UTC+13:45!!

Venezuela hasta mayo de 2016 estaba en UTC-4:30 pero ahí cambiaron y ahora están a UTC-4:00.

MITO 7.- La máxima diferencia horaria posible es de 24 horas

Si la tierra es redonda (aunque ahora ya parece que se puede dudar de todo por idiota que parezca) y se divide en 24 husos horarios, lo lógico parecería que el máximo y mínimo sobre UTC deberían ser +12:00 y -12:00 horas respectivamente ¿no?

Pues no. Lo cierto es que no existe nada inferior a UTC-12:00, que es la hora que observan muchas regiones extremas de Rusia (Kamchatka por ejemplo) y de Oceanía (las islas Marshall por ejemplo). Pero sí que existen zonas horarias de UTC+13:00 y UTC+14:00.

Por ejemplo algunas islas de Oceanía, como Samoa o Kiribati, observan UTC+13:00 y llegan a +14 en horario de verano. ¿Cómo es esto posible? Pues se trata de cuestiones geo-políticas y económicas. En 1995 Kiribati se movió de las zonas -11 y -10 que tenían a las hasta entonces inexistentes +13 y +14 porque querían evitar que el país estuviese dividido por la línea internacional de fechas (IDL). Ese cambio significó que la IDL rodeaba el país.

Un momento... ¿cómo es que pasaron de menos 10 a más 14??? Si te fijas, estas islas están todas situadas justo en la zona de GMT en el Pacífico, por lo que en realidad están muy cerca del extremo que acaba de "dar la vuelta" a los husos horarios. Pueden escoger si están por delante o por detrás de UTC sin ningún problema, ya que se ubican muy cerca de la línea que marca el "origen del tiempo". En este caso pasaron de estar por detrás a estar por delante y sigue siendo coherente. Escogen a voluntad 🙌

Teniendo esa hora, el año nuevo empieza en la República Pacífica de Kiribati antes que ningún otro país del mundo y pensaron que sería una buena atracción turística de cara al año 2000 (que fue un cambio de siglo y atrajo mucho mito alrededor, por no hablar del efecto 2000).

Todo esto significa también que la diferencia horaria entre los dos husos más extremos puede ser mayor que 24 horas. Aunque parezca imposible. En realidad puede llegar a ser de 26 horas.

En resumen

Como todo lo que rodea al ser humano, algo que a priori debería ser exacto y casi "matemático" se complica enormemente al entrar en juego cuestiones políticas y económicas. Y el tiempo no es una excepción. Más bien es un muestrario antológico de esta realidad compleja.

Aunque por suerte los sistemas operativos, lenguajes y plataformas, así como ciertas bibliotecas de apoyo nos ayudan a aislarnos de estas complejidades hasta cierto punto, es importante que las conozcamos. Aparte de ser cuestiones muy interesantes (no me lo vas a negar), conocerlas puede ayudarnos a determinar problemas complejos que nos surjan a la hora de trabajar con fechas y horas. Y es que no siempre podemos confiar ciegamente en que los sistemas se actualicen correctamente (Linux por ejemplo tarda bastante en ocasiones en cambiar esta información), los usuarios los tengan actualizados, o las bibliotecas de apoyo tengan todos los casos contemplados.

En una ocasión posterior intentaré escribir un artículo sobre el manejo de fechas y zonas horarias con JavaScript que creo ilustrará muy bien las complejidades que pueden surgir aún teniendo el apoyo del sistema y del lenguaje. También intentaré aportar algunas buenas prácticas a la hora de trabajar con fechas y horas en C# y la plataforma .NET.

Mientras tanto, ¡espero que te haya parecido interesante!

José Manuel Alarcón Director de campusMVP, es ingeniero industrial y especialista en consultoría de empresa. Ha escrito diversos libros, habiendo publicado hasta la fecha cientos de artículos sobre informática e ingeniería en publicaciones especializadas. Puedes seguirlo en Twitter en @jm_alarcon o leer sus blog técnico o personal. Ver todos los posts de José Manuel Alarcón

No te pierdas ningún post

Únete gratis a nuestro canal en Telegram y te avisaremos en el momento en el que publiquemos uno nuevo.

Archivado en: General

Comentarios (3) -

Juan Carlos
Juan Carlos

gracias, puntos muy válidos a tener presente para el desarrollo.

Responder

Yo me encontre con problema de horas con los contadores de luz. Al grabar datos en base de datos salto excepción en el hilo y no se guardo. Era una situación imposible, pensaba yo entonces, pero luego entendí que era un caso raro, pero si que posible.
Al guardar la hora como clave primaria en base de datos, y que esta hora DateTime.Now parece siempre diferente si lo guardas cada minuto. Pero cuando se retrasa la hora vuelves durante una hora grabar los mismos minutos y aquí empiezas a perder información. Al final se opto por añadir un campo mas que indica si es hora de verano o si es hora de invierno y la clave primaria ahora es compuesta.

Responder

José Manuel Alarcón
José Manuel Alarcón

Hola Anton: gracias por comentar.

Sí, hay muchos detalles como esos. Tengo que ver si saco tiempo para escribir algo sobre el uso concreto de horas y fechas en algunos lenguajes cono C# o JavaScript, donde hay todo tipo de casos curiosos.

Saludos!

Responder

Agregar comentario