1735689600 não significa nada até saberes que é um timestamp Unix: o número de segundos decorridos desde 1 de janeiro de 1970 às 00:00:00 UTC (a "epoch"). É o formato de data mais usado em bases de dados, APIs e JWTs, e também a origem de um dos bugs mais repetidos em JavaScript.
O bug dos três zeros
Unix conta em segundos. O JavaScript, pelo contrário, constrói datas a partir de milissegundos:
new Date(1735689600) // ❌ 1970-01-21 — 50 anos errado!
new Date(1735689600 * 1000) // ✅ 2025-01-01
Se a tua API devolve segundos (como quase tudo o que não é JavaScript: Python, PHP, SQL) e passas esse número diretamente para new Date(), obténs uma data de 1970. Multiplica por 1000 — ou, se o valor já vier em milissegundos, não multipliques — o erro vai quase sempre nesse sentido.
Porque UTC e não a tua hora local
Um timestamp Unix não tem fuso horário: é um contador absoluto de segundos, igual em Lisboa e em Tóquio. O fuso horário só entra em jogo ao mostrá-lo — por isso dois servidores em continentes diferentes podem comparar timestamps diretamente sem complicações, e por isso é o formato preferido para created_at, o exp de um JWT ou chaves de cache.
O problema do ano 2038
Os sistemas que ainda guardam o timestamp num inteiro de 32 bits com sinal ficam sem números a 19 de janeiro de 2038 (o famoso Y2038). É o mesmo tipo de bug que o Y2K, mas afeta sistemas embebidos, bases de dados antigas e algum time_t em C que ninguém migrou para 64 bits. Se trabalhas com IoT ou firmware, já devias estar a verificar isto.
Como evitar a confusão
Converte em ambas as direções com o conversor de timestamp Unix: cola o número e vê a data no teu fuso horário e em UTC, ou ao contrário — escolhe uma data e obtém o timestamp exato. Se precisares de comparar a mesma hora em várias cidades, usa o conversor de fusos horários; e se o que queres é calcular quantos dias há entre duas datas (não timestamps), a calculadora de diferença entre datas faz a conta sem teres de subtrair timestamps à mão.