Convertidor Fecha/Hora

Que son los formatos de fecha?

Un formato de fecha define como un valor de fecha y/u hora se representa como texto. El mismo instante en el tiempo, digamos, el quince de marzo de 2024 a las dos y media de la tarde en Londres, puede escribirse de docenas de formas dependiendo del formato, la configuracion regional y la zona horaria:

• 2024-03-15T14:30:00Z (ISO 8601)
• 1710513000 (marca de tiempo Unix)
• Fri, 15 Mar 2024 14:30:00 +0000 (RFC 2822)
• 03/15/2024 2:30 PM (formato de EE. UU.)
• 15/03/2024 14:30 (formato europeo)
• 2024年3月15日 14時30分 (japones)

La conversion de formatos de fecha transforma marcas de tiempo entre estas representaciones. Esto es critico para el intercambio de datos entre sistemas, APIs, bases de datos e interfaces de usuario que esperan diferentes formatos.

ISO 8601: el estandar universal

ISO 8601 es el estandar internacional para la representacion de fecha y hora. Usa un formato estricto e inequivoco que elimina la confusion entre el ordenamiento de fechas estadounidense y europeo:

YYYY-MM-DDThh:mm:ss±hh:mm
2024-03-15T14:30:00+01:00

Propiedades clave de ISO 8601:

• Ano primero: Elimina la ambiguedad DD/MM vs MM/DD
• Separador T: Divide claramente la fecha del tiempo
• Desplazamiento de zona horaria: Indica explicitamente el desplazamiento respecto a UTC
• Sufijo Z: Abreviatura para UTC (desplazamiento cero)
• Ordenamiento lexicografico: Las cadenas ISO 8601 se ordenan correctamente como texto plano

ISO 8601 es el formato predeterminado para APIs JSON, el Date.toISOString() de JavaScript, PostgreSQL y la mayoria de los estandares modernos de intercambio de datos.

Marcas de tiempo Unix

Una marca de tiempo Unix (tambien llamada tiempo de epoca o tiempo POSIX) representa un instante como el numero de segundos transcurridos desde el 1 de enero de 1970 00:00:00 UTC, la epoca Unix.

1710513000 = 2024-03-15T14:30:00Z

Las marcas de tiempo Unix son compactas, inequivocas, neutrales en cuanto a zona horaria (siempre UTC) y trivialmente comparables (solo comparacion de enteros). Son la representacion interna estandar del tiempo en la mayoria de los lenguajes de programacion y bases de datos.

Variante	Unidad	Rango	Desbordamiento
Unix (32 bits)	Segundos	1970 - 2038	19 ene, 2038
Unix (64 bits)	Segundos	1970 - 292 mil millones de anos	Nunca (practicamente)
Milisegundos	ms	1970 - futuro lejano	Estandar de JavaScript
Microsegundos	us	1970 - futuro lejano	PostgreSQL, Python

JavaScript usa milisegundos desde la epoca (Date.now() devuelve milisegundos). Muchas APIs y bases de datos usan segundos. Siempre verifique que unidad espera su sistema.

Referencia de formatos

Formato	Ejemplo	Usado por
ISO 8601	2024-03-15T14:30:00Z	APIs, JSON, bases de datos
Unix (segundos)	1710513000	Internos del sistema, logging
Unix (milisegundos)	1710513000000	JavaScript, Java
RFC 2822	Fri, 15 Mar 2024 14:30:00 +0000	Encabezados de email, HTTP
Legible por humanos	March 15, 2024 2:30 PM EST	Visualizacion en UI, reportes
SQL	2024-03-15 14:30:00	Bases de datos (sin T, sin Z)

Zonas horarias y UTC

Las zonas horarias son la mayor fuente de bugs relacionados con fecha/hora. Hay mas de 400 identificadores de zona horaria en la base de datos de zonas horarias IANA, y cambian regularmente: los paises adoptan, modifican o eliminan el horario de verano, cambian su desplazamiento UTC o se dividen en nuevas zonas.

Errores comunes:

• Transiciones de horario de verano: Los relojes “adelantan” (perdiendo una hora) y “atrasan” (ganando una hora). Una marca de tiempo como “2024-03-10 02:30 America/New_York” no existe: los relojes saltaron de las 2:00 a las 3:00.
• Las abreviaturas de zona horaria son ambiguas: “CST” es Central Standard Time (UTC-6), China Standard Time (UTC+8) y Cuba Standard Time (UTC-5). Siempre use identificadores de zona horaria IANA (America/Chicago, Asia/Shanghai).
• Desplazamientos no enteros: India es UTC+5:30, Nepal es UTC+5:45 y las Islas Chatham (Nueva Zelanda) son UTC+12:45.

Errores comunes

1. Almacenar hora local sin zona horaria. Un simple 2024-03-15 14:30:00 no tiene sentido sin saber a que zona horaria se refiere. Siempre almacene UTC o incluya el desplazamiento.

2. Asumir 24 horas en un dia. Las transiciones de horario de verano crean dias de 23 y 25 horas. La aritmetica de tiempo que suma 86400 segundos para avanzar un dia sera incorrecta dos veces al ano.

3. Usar abreviaturas de zona horaria. “PST” y “PDT” son desplazamientos diferentes. Use America/Los_Angeles y deje que la biblioteca determine el desplazamiento correcto para cualquier fecha dada.

4. Ignorar los segundos intercalares. UTC ocasionalmente agrega un segundo intercalar (23:59:60). La mayoria de los sistemas ignoran los segundos intercalares, pero GPS time, NTP y algunos sistemas financieros los tienen en cuenta.

Casos de uso comunes

• Integracion de APIs: Convertir marcas de tiempo entre el formato que devuelve su API (ISO 8601, Unix) y el formato que espera su base de datos o frontend
• Correlacion de logs: Convertir marcas de tiempo de diferentes servicios (cada uno posiblemente en diferentes formatos y zonas horarias) a un formato comun para analisis unificado de logs
• Programacion entre zonas horarias: Convertir horarios de reuniones, ventanas de despliegue o programaciones de mantenimiento entre las horas locales de los miembros del equipo
• Migracion de datos: Transformar columnas de fecha al mover datos entre bases de datos con diferentes formatos de marca de tiempo (epoca Unix en Redis vs ISO 8601 en PostgreSQL)
• Depuracion de bugs de tiempo: Convertir marcas de tiempo Unix de logs de errores a fechas legibles por humanos para entender cuando ocurrieron los eventos