1735689600 no significa nada hasta que sabes que es un timestamp Unix: el número de segundos transcurridos desde el 1 de enero de 1970 a las 00:00:00 UTC (el "epoch"). Es el formato de fecha más usado en bases de datos, APIs y JWTs, y también el origen de uno de los bugs más repetidos en JavaScript.
El bug de los tres ceros
Unix cuenta en segundos. JavaScript, en cambio, construye fechas a partir de milisegundos:
new Date(1735689600) // ❌ 1970-01-21 — ¡50 años mal!
new Date(1735689600 * 1000) // ✅ 2025-01-01
Si tu API devuelve segundos (como casi todo lo que no sea JavaScript: Python, PHP, SQL) y le pasas ese número directo a new Date(), obtienes una fecha de 1970. Multiplica por 1000 o, si el valor ya viene en milisegundos, no lo multipliques — el error casi siempre es en esa dirección.
Por qué UTC y no tu hora local
Un timestamp Unix no tiene zona horaria: es un contador absoluto de segundos, igual en Madrid que en Tokio. La zona horaria solo entra en juego al mostrarlo — por eso dos servidores en continentes distintos pueden comparar timestamps directamente sin líos, y por qué es el formato preferido para created_at, exp de un JWT o claves de caché.
El problema del año 2038
Los sistemas que aún guardan el timestamp en un entero de 32 bits con signo se quedan sin números el 19 de enero de 2038 (el famoso Y2038). Es el mismo tipo de bug que el Y2K, pero afecta a sistemas embebidos, bases de datos antiguas y algún que otro time_t en C que nadie ha migrado a 64 bits. Si trabajas con IoT o firmware, ya deberías estar comprobándolo.
Cómo evitarte el lío
Convierte en ambas direcciones con el convertidor de Timestamp Unix: pega el número y verás la fecha en tu zona horaria y en UTC, o al revés, elige una fecha y obtén el timestamp exacto. Si necesitas comparar la misma hora en varias ciudades, usa el conversor de zonas horarias; y si lo que quieres es calcular cuántos días hay entre dos fechas (no timestamps), el calculador de diferencia entre fechas hace la cuenta sin que tengas que restar timestamps a mano.