Un usuario de una de mis aplicaciones de Laravel SaaS una vez enviada por correo electrónico para decir que la fecha de renovación de su suscripción parecía "un poco generosa". La página de facturación le dijo que su plan se renovaría el 25 de abril del año. 57123.
El error me tomó vergonzosamente largo encontrar porque cada pieza individual era correcta. La interfaz de reacción enviada Date.now()- care se devuelve milisegundos- y el backend de PHP lo hizo date('Y-m-d', $timestamp), que espera artículos de segunda clase. pienso 1740470400000 en una función esperando 1740470400 Y aterrizas aproximadamente 55.000 años en el futuro. Sin excepción, sin advertencia, sin prueba fallida. Solo un cliente que pregunta cortésmente si su suscripción realmente duró hasta la muerte por calor de la civilización.
Las marcas de tiempo parecen el tema más aburrido en el software. En realidad, son una de las fábricas de errores más confiables que tenemos: segundos frente a milisegundos, UTC frente a las transiciones DST, la transferencia de DST, la transferencia de 2038. los Convertidor de marca de tiempo en Toolz.dev existe porque me cansé de hacer new Date(x * 1000) en una consola de navegador cuarenta veces al día. Esta guía cubre lo que reviso ahora, en el orden en que lo reviso.
TL;Dr: Una marca de tiempo Unix cuenta segundos desde 1970-01-01T00:00:00 UTC. 10 dígitos = segundos, 13 dígitos = milisegundos- mezclarlos pone tus fechas en 55.000 años de descuento. Almacene UTC, convierta solo para mostrar, use nombres de zonas de la IANA como
Asia/Dhakaen lugar de abreviaturas. Pegue cualquier marca de tiempo en el Convertidor de marca de tiempo para obtener los formularios ISO 8601, RFC 2822, local y UTC, se ejecuta en el lado del cliente, por lo que las marcas de tiempo están fuera JWT Y los registros de producción nunca abandonan su navegador.
¿Qué es una marca de tiempo de Unix, exactamente?
Una marca de tiempo Unix (tiempo de época, tiempo POSIX) es el número de segundos transcurridos desde 1 de enero de 1970, 00:00:00 UTC- el "Epoca Unix." It' es un único número entero, no tiene zona horaria (it' siempre UTC por definición) y, efectivamente, todos los sistemas operativos, idiomas y bases de datos lo entienden. Esa última propiedad es la razón por la que sobrevivió cinco décadas: es el formato único sobre el que nadie discute.
¿por qué 1970? No hay razón profunda: era una fecha redonda conveniente cerca de cuando se estaba construyendo Unix en Bell Labs, y los primeros Unix contaban el tiempo en un número entero de 32 bits. La elección arbitraria se fosilizó en un estándar universal, que es muy Unix.
Algunos puntos de referencia que vale la pena reconocer a la vista:
| marca de tiempo | Fecha UTC | por qué lo verías |
|---|---|---|
0 |
1970-01-01 00:00:00 | La época. También lo que obtienes de null/0 errores: una fecha en 1970 en la pantalla casi siempre significa un valor no inicializado, no un viaje en el tiempo |
946684800 |
2000-01-01 00:00:00 | Y2K |
1234567890 |
2009-02-13 23:31:30 | Los desarrolladores en realidad organizaron fiestas para este |
1740470400 |
2025-02-25 08:00:00 | Una marca de tiempo moderna de 10 dígitos ordinaria |
2147483647 |
2038-01-19 03:14:07 | El máximo con signo de 32 bits; consulte Y2038 a continuación |
Esa cuarta fila es mi ejemplo favorito por una razón sutil: muchas páginas de tutoriales listan 1740470400 como "25 de febrero de 2025, 12:00:00". En realidad es 08:00 UTC- alguien lo convirtió una vez en su zona horaria local y desde entonces se ha copiado y pegado el valor incorrecto. Verifique las marcas de tiempo con una herramienta, no con una publicación de blog. Incluyendo este.
Segundos o milisegundos: ¿cómo se puede saber?
Cuente los dígitos. Para cualquier fecha de la era actual:
- 10 dígitos (
1740470400) - secunde. Convención Unix, la mayoría de las API, PHP'stime(), Pythontime.time()(como flotador), Stripe's API. - 13 dígitos (
1740470400000) - milisegundos. JavaScript'sDate.now(), JavaSystem.currentTimeMillis(), fechas de MongoDB.
Esta es la distinción exacta que produjo mi fecha de renovación del año 57123, por lo que detallaré los modos de falla:
- MS interpretada como segundos → fechas ~55.000 años en el el porvenir
- Segundos interpretados como MS → Fechas en enero de 1970 (Todo se derrumba dentro de ~3 semanas de la época)
Si ve una firma (fechas antiguas o fechas absurdas de un futuro lejano), conocerá el error antes de leer una línea de código. El Convertidor de marca de tiempo Detecta el recuento de dígitos y etiqueta ambas interpretaciones, que resuelve el argumento "es este S o MS" en dos segundos.
¿Qué formatos de fecha realmente necesitas saber?
Tres cubren casi todo lo que toca un desarrollador en funcionamiento.
ISO 8601- el estándar internacional, y lo que debes emitir en API y registros:
2026-07-13T09:30:45Z UTC ("Z" = Zulu)
2026-07-13T15:30:45+06:00 with timezone offset
2026-07-13T09:30:45.123Z with milliseconds
La característica asesina que nadie menciona: cadenas ISO 8601 Ordenar lexicográficamente en orden cronológico. sort En un archivo de registro simplemente funciona. 02/25/2026-los formatos de estilo pueden ' No hagas eso y, peor aún, Estados Unidos MM/DD y europeo DD/MM son indistinguibles durante los doce días de cada mes.
RFC 3339 (especulación) - el perfil de protocolo de Internet de ISO 8601. Ligeramente más estricto; si tu API emite 2026-07-13T09:30:45Z Satisfaces a ambos. Este es el formato para estandarizar.
RFC 2822 (Sun, 13 Jul 2026 09:30:45 +0000) - encabezados de correo electrónico y HTTP, canales RSS. Lo lees con más frecuencia de lo que lo escribes.
Los formatos de base de datos son primos cercanos: MySQL DATETIME es 2026-07-13 09:30:45 (ISO con un espacio), PostgreSQL timestamptz Renders 2026-07-13 09:30:45+00.
¿Cómo manejan los idiomas que uso las marcas de tiempo?
Los tres de mi propia pila y la peculiaridad de cada uno que personalmente me ha costado tiempo.
JavaScript (el de MS):
Math.floor(Date.now() / 1000) // current Unix seconds — Date.now() is ms!
new Date(1740470400 * 1000) // seconds → Date: multiply by 1000
date.toISOString() // "2025-02-25T08:00:00.000Z"
Date.parse('2026-07-13T09:30:45Z') / 1000 // ISO string → Unix seconds
Quirk: todo son milisegundos, y new Date(1740470400) Silently le da el 21 de enero de 1970 en lugar de febrero de 2025. Sin error. Esta asimetría es el error de marca de tiempo más común en el desarrollo web.
feb (el segundo):
time(); // current Unix seconds
date('Y-m-d H:i:s', 1740470400); // "2025-02-25 08:00:00" (server TZ!)
strtotime('2026-07-13 09:30:45'); // string → timestamp
(new DateTime('@1740470400'))
->setTimezone(new DateTimeZone('Asia/Dhaka'))
->format(DateTime::ATOM); // "2025-02-25T14:00:00+06:00"
Peculiaridad: date() formatos en el servidor Zona horaria predeterminada, por lo que el mismo código imprime diferentes fechas en su máquina y en producción. también, new DateTime('@1740470400') ignora cualquier zona horaria que pase al constructor: el @ el formulario siempre es UTC; debe llamar setTimezone() después WordPress agrega su propia capa: current_time('timestamp') Devuelve una "fantamp" de "local" de tiempo real de Unix, que es exactamente tan peligroso como parece.
pitón:
import time, datetime
int(time.time()) # current Unix seconds
datetime.datetime.fromtimestamp(1740470400,
tz=datetime.timezone.utc) # → aware datetime
dt.isoformat() # "2025-02-25T08:00:00+00:00"
Peculiaridad: fromtimestamp() sin tz= Devuelve una fecha y hora ingenua en la hora local. Las fechas ingenuas son el error de la hora de Python: se comparan y se restan felizmente entre sí hasta el día en que uno de ellos cruzó un límite de DST. siempre pasa tz=; usar zoneinfo (stdlib desde 3.9) para zonas con nombre.
¿Cómo debe manejar las zonas horarias sin perder la cabeza?
Cuatro reglas, todas aprendidas de la manera molesta:
- Tienda UTC. Siempre. Marcas de tiempo UNIX o
timestamptzen la base de datos. La zona horaria se convierte en una preocupación de visualización solamente. - Convertir en la capa de presentación. El usuario de Dhaka ve
+06:00, el usuario en Berlín ve+02:00, la base de datos no ve ninguno. - Use nombres de IANA, no abreviaturas.
Asia/Dhaka,America/New_York,Europe/Berlin. Las abreviaturas son ambiguas -CSTsignifica hora estándar central de EE. UU., China o hora estándar de Cuba según quién y #39;s lectura - y abreviaturas don't codifican reglas DST. Los nombres de la IANA sí lo hacen. - Nunca lances la lógica de DST de la mano. Las fechas de DST difieren según el país, el cambio por legislación y algunos lugares (Arizona, Bangladesh, Japón) no observan en absoluto el horario de verano. La base de datos IANA TZ existe porque esto es realmente difícil; use la biblioteca que la envuelve.
El corolario de la Regla 1: Cuando dos sistemas no están de acuerdo sobre un tiempo de evento, convierta ambos valores en marcas de tiempo UTC UNIX y compare los enteros. Argumentos sobre "pero dice 3 pm aquí'' disolverse al instante.
¿Cuál es el problema de Y2038 y debería importarle?
Un entero de 32 bits con signo se encuentra en un máximo de 2,147,483,647. Como una marca de tiempo de Unix, eso 19 de enero de 2038, 03:14:07 UTC. Un segundo después, el valor se vuelve negativo: hasta el 13 de diciembre de 1901.
Suena muy lejos; es 't, por dos razones. Primero, es aproximadamente 11,5 años después de escribir esto, dentro de la vida útil de los sistemas integrados, los controladores industriales y ese servicio heredado que nadie quiere tocar. Segundo, el porvenir Las fechas golpean la pared antes de tiempo: un sistema que calcula un calendario de hipotecas de 15 años o un certificado de 20 años que vence cruza 2038 hoy. m sql TIMESTAMP el tipo de columna es la trampa clásica: it's con límite de 32 bits y can't fechas de la tienda después del 19 de enero de 2038, mientras DATETIME en la misma base de datos está bien.
Estás a salvo en 64 bits time_t (cualquier sistema operativo moderno), JavaScript (float64 ms), Python (precisión arbitraria) y PostgreSQL. Estás en riesgo en sistemas integrados de 32 bits, antiguo TIMESTAMP columnas y código C que codificado int32_t por el tiempo La prueba es simple: empujar 2147483648 (Uno más allá del límite) a través de su canalización y vea qué sale. los Convertidor de marca de tiempo Con gusto generará los valores de la prueba posteriores a 2038.
¿Dónde aparecen las marcas de tiempo en la depuración real?
Expiración de JWT. Las fichas llevan iat y exp Reclamaciones como segundos de UNIX:
{ "sub": "user_8241", "iat": 1783915890, "exp": 1783919490 }
"¿Por qué se cierra este usuario? ¿Se responde con la conversión de este exp. Decodificar el token en el Decodificador JWT y convierta el reclamo; ambos ejecutan el lado del cliente, lo cual es importante porque un token pegado es una credencial activa (el Guía de privacidad de datos Cubre por qué me niego a poner tokens en herramientas del lado del servidor).
Correlación de registro. Un incidente, tres servicios, tres formatos: NGINX Logs [13/Jul/2026:09:30:45 +0000], la aplicación registra ISO 8601, un trabajador de cola registra segundos de época sin procesar. Convertir todo a un formato es el paso cero de la creación de una línea de tiempo.
Integración de API. envíos de rayas "created": 1740470400 (segundos). Una API construida en JavaScript envía 1740470400000 (ms). Las API de Google envían cadenas RFC 3339. Si consume los tres, la conversión es 't ocasional - it's constante. Formatee las cargas útiles en el Formateador JSON y convertir los campos interesantes.
Consultas de intervalo de fechas. WHERE created_at >= 1752364800 AND created_at < 1752451200- ¿es ese el día adecuado? Convierte ambos límites y comprueba, en UTC, antes de ejecutar la eliminación. RELACIONADO: El Calculadora de diferencia de fecha ¿Por cuántos días entre estos dos?, el Convertidor de zona horaria para las matemáticas de la reunión y el analizador de cron Para "cuándo se dispara realmente este horario?".
Preguntas frecuentes
¿Qué es una marca de tiempo de Unix?
El número de segundos transcurridos desde el 1 de enero de 1970 a las 00:00:00 UTC (la época de Unix), almacenados como un solo número entero. It's independiente de la zona horaria por definición - el mismo instante es el mismo número en todas partes de la Tierra - razón por la cual 's el formato de intercambio estándar entre sistemas operativos, idiomas y bases de datos.
¿Por qué algunas marcas de tiempo tienen 10 dígitos y otras 13?
10 dígitos son segundos (convención estándar de UNIX, PHP, la mayoría de las API); 13 dígitos son milisegundos (JavaScript'S Date.now(), Java). Divida por 1000 para pasar de MS a segundos. Confundir las dos fechas de turnos ~ 55.000 años en el futuro o de regreso a enero de 1970.
¿Pueden las marcas de tiempo de UNIX representar fechas anteriores a 1970?
Sí, los valores negativos cuentan hacia atrás desde la época. -86400 es el 31 de diciembre de 1969. Una marca de tiempo firmada de 32 bits se remonta al 13 de diciembre de 1901. Sin embargo, algunos sistemas y API rechazan marcas de tiempo negativas, así que pruebe antes de confiar en ellas.
¿Cuál es el problema de Y2038?
Las marcas de tiempo firmadas de 32 bits se desbordan a 2147 483 647 - 19 de enero de 2038, 03:14:07 UTC - hasta diciembre de 1901. Los sistemas modernos de 64 bits no se ven afectados, pero sí los dispositivos integrados de 32 bits, el código C heredado y MySQL TIMESTAMP Las columnas están expuestas. Sistemas de computación de futuros lejanos (hipotecas, certificados) se golpean años antes de que llegue 2038.
¿Por qué mi fecha se muestra en enero de 1970?
Una marca de tiempo cero o casi cero alcanzó su código de formato, generalmente un valor no inicializado, un análisis fallido que devuelve 0 o segundos pasados donde se esperaban milisegundos. Una fecha de 1970 en la pantalla casi nunca es un punto de datos; it' es nulo con un disfraz.
¿Debo almacenar marcas de tiempo o cadenas de fecha y hora en mi base de datos?
Almacene UTC de cualquier manera: el tipo importa menos que la disciplina de zona horaria. Los números enteros de Unix son compactos, se clasifican trivialmente y evitan el análisis por completo; timestamptz/DATETIME las columnas son legibles por humanos en los resultados de las consultas y admiten aritmética de fechas en SQL. Lo que no debe hacer es almacenar los horarios locales sin compensaciones, eso y #39;s pérdida de datos que solo descubre en la siguiente transición DST.
¿La época se ve afectada por los segundos bisiestos?
Prácticamente no. El tiempo Unix pretende segundos intercalares don' No existe: cada día es exactamente 86.400 segundos y los sistemas normalmente difuminan o hacen un paso el reloj cuando ocurre un segundo intercalar. Para el código de aplicación, esto no es un problema; sólo importa en contextos de sincronización científica, donde en su lugar se utiliza la hora TAI o GPS.
¿Es seguro pegar marcas de tiempo de registro de producción en un conversor en línea?
Una marca de tiempo sin procesar por sí sola revela poco, pero las marcas de tiempo generalmente viajan con contexto: ID de usuario, afirmaciones de tokens, líneas de registro. El Convertidor de marca de tiempo En Toolz.dev se convierte completamente en su navegador sin que se transmitan datos, por lo que pegar valores directamente de los registros de producción o JWT no expone nada.
¿Cómo convierto una marca de tiempo de Unix en una fecha legible?
Pegue el número en un convertidor y lea los resultados UTC y locales, o hágalo en código: new Date(ts * 1000).toISOString() En JavaScript, datetime.fromtimestamp(ts, tz=timezone.utc) En pitón, date -u -d @ts en Linux. Lo único que hay que hacer bien primero es si su valor está en segundos o milisegundos; todo lo demás se deriva de eso.
¿Cómo obtengo la marca de tiempo actual de Unix?
date +%s En una concha, Math.floor(Date.now() / 1000) En JavaScript, int(time.time()) En pitón, SELECT EXTRACT(EPOCH FROM NOW()) en PostgreSQL. Tenga en cuenta que JavaScript es el extraño: Date.now() Devuelve milisegundos, por lo que la división no es opcional.
