Trabajar con zonas horarias y marcas de tiempo Unix sin errores
Las fechas y horas causan una cantidad desproporcionada de errores, porque lo que a un humano le parece obvio es genuinamente complicado para un ordenador: las zonas horarias cambian, los relojes saltan una hora dos veces al año y 'hoy' depende de dónde estés parado. Esta guía explica las ideas centrales y te da un puñado de reglas que evitan la mayoría de los fallos al manejar fechas.
Almacena el tiempo como un instante absoluto
La regla más importante: almacena y transmite los momentos como un instante absoluto e independiente de la zona horaria — una marca de tiempo Unix (segundos o milisegundos desde el 1 de enero de 1970 UTC) o una cadena ISO 8601 en UTC (terminada en Z). Un instante es el mismo en toda la Tierra; solo cambia su representación humana.
Convierte a una zona horaria local solo en el borde mismo, cuando muestras el valor a una persona. Mantén el interior de tu sistema en UTC. La mayoría de los errores de fechas dolorosos vienen de almacenar una hora 'local' sin registrar a qué zona pertenecía, dejando el valor ambiguo para siempre.
UTC, desfases y zonas horarias no son lo mismo
UTC es el reloj de referencia global. Un desfase como +09:00 es un desplazamiento fijo respecto a UTC en un momento. Una zona horaria, como America/New_York, es un conjunto de reglas con nombre que describe qué desfase aplica en cada punto de la historia — incluido cuándo cambia.
La distinción importa porque los desfases cambian dentro de una sola zona. Nueva York es -05:00 en invierno y -04:00 en verano. Almacenar solo un desfase pierde la regla, así que no puedes calcular correctamente una hora local futura. Por eso programar 'cada día a las 9 de la mañana hora de Nueva York' necesita el nombre de la zona, no un desfase fijo.
El horario de verano rompe las suposiciones ingenuas
Dos veces al año, las zonas que observan el horario de verano saltan. En primavera se omite una hora, así que una hora local como las 02:30 simplemente no existe ese día; en otoño se repite una hora, así que la 01:30 ocurre dos veces y es ambigua. El código que asume que cada día tiene 24 horas, o que una hora local dada siempre existe, acabará produciendo resultados erróneos o fallando.
Trabajar en UTC esquiva esto por completo, porque UTC no tiene horario de verano. Solo te enfrentas a los huecos y solapamientos al convertir a hora local para mostrar o al interpretar la entrada humana — que es justo donde una biblioteca de fechas probada debería hacer el trabajo en lugar de aritmética casera.
Segundos, milisegundos y el año 2038
Las marcas de tiempo Unix vienen en dos unidades comunes y mezclarlas es un error frecuente: la mayoría de las herramientas y APIs Unix usan segundos, mientras que el Date de JavaScript trabaja en milisegundos. Un valor desviado por un factor de 1000 suele significar que se confundieron las unidades — una marca de tiempo de repente en el año 56000, o de vuelta en 1970.
También hay un límite de tamaño: un tiempo Unix almacenado en un entero con signo de 32 bits se desborda el 19 de enero de 2038. Los sistemas modernos usan valores de 64 bits, lo que elimina el problema a efectos prácticos, pero vale la pena saber por qué los sistemas antiguos manejan mal las fechas muy lejanas.
Reglas que evitan la mayoría de los errores
Nada de esto requiere experiencia profunda en el día a día — unos pocos hábitos cubren la gran mayoría de los casos.
- Almacena e intercambia instantes en UTC (marca de tiempo Unix o ISO 8601 con Z); convierte a local solo para mostrar.
- Conserva el nombre de zona IANA (p. ej. Europe/Paris) cuando importe una hora local futura; un desfase por sí solo no basta.
- Nunca hagas cálculos de calendario sumando números fijos de segundos para 'un día' o 'un mes' — usa una biblioteca de fechas que conozca el horario de verano y la duración de los meses.
- Sé explícito sobre segundos vs milisegundos en cada frontera, y etiqueta cuál quieres decir.