Conversor de timestamp

Un timestamp Unix es simplemente el número de segundos transcurridos desde medianoche UTC del 1 de enero de 1970 — un punto de referencia arbitrario elegido hace décadas que desde entonces se ha convertido en el valor por defecto casi universal para representar un punto en el tiempo dentro de un sistema informático. El atractivo es que reduce una fecha y hora a un solo entero fácil de comparar y almacenar: comprobar si un momento es anterior a otro es una simple comparación numérica en lugar de un cálculo de calendario, y almacenarlo ocupa una cantidad fija y predecible de espacio sin importar en qué siglo caiga la fecha. Por esto subyace a todo, desde columnas de timestamp en bases de datos hasta respuestas de API y entradas de archivos de registro, aunque el número crudo no tenga ningún significado para una persona que lo mira directamente — que es la razón entera por la que existe un conversor como este.

Un timestamp Unix que representa el momento actual en segundos tiene diez dígitos de longitud, y el mismo instante expresado en milisegundos tiene trece — tres dígitos adicionales para la precisión de milésimas. Esta diferencia de longitud es la forma rápida y fiable de identificar en qué unidad está un número dado, y también explica los dos modos de fallo más comunes y confusos cuando se hace la suposición equivocada. Pasar un valor en milisegundos a código que espera segundos multiplica la fecha aparente por aproximadamente mil, cayendo en algún lugar del año 55000 — espectacular y obviamente mal. Pasar un valor en segundos a código que espera milisegundos hace lo contrario: divide el tiempo transcurrido real por aproximadamente mil, lo que hace que la fecha interpretada caiga en algún lugar de 1970, lo bastante cerca de una fecha plausible como para a veces confundirse con un error genuino en otro lugar en lugar de un desajuste de unidades.

Un timestamp Unix crudo no lleva ninguna información de zona horaria en absoluto — es simplemente un conteo de segundos transcurridos, idéntico en cualquier lugar de la Tierra en un instante dado — y el momento de convertirlo a una fecha legible es donde hay que elegir una zona horaria con propósitos de visualización. Almacenar y registrar eventos usando UTC (o el propio timestamp crudo, que es independiente de la zona horaria por definición) significa que cada registro en un sistema representa exactamente el mismo instante sin importar en qué zona horaria resulte estar el servidor, la base de datos, o la persona que lee el registro. Convertir a hora local es una decisión de la capa de visualización tomada solo cuando un humano realmente está mirando el valor, por lo que esta herramienta separa los dos claramente: UTC e ISO 8601 como los valores que vale la pena almacenar y comparar, hora local como la versión que vale la pena leer.

Una cantidad significativa de infraestructura más antigua — código C heredado, algunos sistemas embebidos, ciertos tipos de columna de base de datos más antiguos — almacena un timestamp Unix en un entero con signo de 32 bits, que tiene un techo firme: se desborda a las 03:14:07 UTC del 19 de enero de 2038 y vuelve a una fecha de 1901, un error con la misma forma subyacente que el problema del Y2K pero arraigado en límites de enteros binarios en lugar de años de dos dígitos. JavaScript representa los números como valores de punto flotante de 64 bits, que tienen muchísimo más margen y no están sujetos a este desbordamiento específico, así que un timestamp calculado en esta herramienta no se ve afectado — la preocupación aplica a cualquier sistema que originalmente produjo el timestamp que se está convirtiendo, no a la conversión que ocurre aquí.