Unix timestamp

O Unix timestamp começa em 1 de janeiro de 1970 às 00:00:00 UTC — uma data escolhida arbitrariamente por Ken Thompson e Dennis Ritchie na Bell Labs quando estavam desenvolvendo o Unix no final da década de 1960. Quando você escreve `time()` em PHP, `Date.now()` em JavaScript ou `datetime.now().timestamp()` em Python, o número que você recebe é a quantidade de segundos ou milissegundos desde esse momento. Por décadas, esse contador foi armazenado como um inteiro de 32 bits com sinal, o que significa que ele vai transbordar em 19 de janeiro de 2038 às 03:14:07 UTC — o Y2K38, o Problema do Ano 2038. Sistemas de 64 bits resolvem isso: um inteiro de 64 bits aguenta aproximadamente 292 bilhões de anos, bem além do prazo de suporte de qualquer software em produção.

O grande trunfo do timestamp Unix é que ele é não-ambíguo por definição. Uma data como `01/02/2025` pode ser 1 de fevereiro ou 2 de janeiro dependendo do locale do sistema. Um timestamp como `1748180200` é um único ponto no tempo, o mesmo em Tóquio, Nova York ou São Paulo. Além disso, timestamps são trivialmente ordenáveis — comparar dois inteiros é mais rápido e simples do que parsear e comparar strings de data. Um detalhe que causa bugs com frequência: `10 dígitos = segundos`, `13 dígitos = milissegundos`. Confundir os dois é um clássico: passar milissegundos onde o código espera segundos resulta numa data equivalente ao ano 57.000, enquanto passar segundos onde se espera milissegundos produz datas em 1970.

A regra de ouro ao trabalhar com timestamps é: armazene sempre em UTC, converta apenas na hora de exibir. Isso evita uma categoria inteira de bugs relacionados ao horário de verão, mudanças de fuso e diferenças de configuração entre servidores. Em JavaScript, `new Date(timestamp * 1000)` cria um objeto `Date` a partir de um timestamp em segundos — o `* 1000` converte para milissegundos, que é o que o construtor espera. Para exibir datas de forma localizada e acessível, o moderno `Intl.DateTimeFormat` é superior ao antigo `toLocaleDateString()`: ele aceita locale explícito, opções de formatação detalhadas e funciona consistentemente em todos os browsers modernos.

The Unix timestamp starts at January 1st, 1970, at 00:00:00 UTC — a date chosen arbitrarily by Ken Thompson and Dennis Ritchie at Bell Labs when they were developing Unix in the late 1960s. When you write `time()` in PHP, `Date.now()` in JavaScript, or `datetime.now().timestamp()` in Python, the number you get is the count of seconds or milliseconds since that moment. For decades this counter was stored as a signed 32-bit integer, which means it will overflow on January 19th, 2038 at 03:14:07 UTC — the Y2K38, the Year 2038 Problem. 64-bit systems solve this: a 64-bit integer can hold approximately 292 billion years, well beyond the support window of any software currently in production.

The great strength of the Unix timestamp is that it is unambiguous by definition. A date like `01/02/2025` can mean January 2nd or February 1st depending on the system locale. A timestamp like `1748180200` is a single point in time, identical in Tokyo, New York, and São Paulo. Timestamps are also trivially sortable — comparing two integers is faster and simpler than parsing and comparing date strings. One detail that causes bugs regularly: `10 digits = seconds`, `13 digits = milliseconds`. Mixing them up is a classic mistake: passing milliseconds where the code expects seconds results in a date equivalent to the year 57,000, while passing seconds where milliseconds are expected produces dates in 1970.

The golden rule when working with timestamps is: always store in UTC, convert only when displaying. This avoids an entire category of bugs related to daylight saving time, timezone changes, and configuration differences between servers. In JavaScript, `new Date(timestamp * 1000)` creates a `Date` object from a seconds-based timestamp — the `* 1000` converts to milliseconds, which is what the constructor expects. For displaying dates in a localized and accessible way, the modern `Intl.DateTimeFormat` is superior to the older `toLocaleDateString()`: it accepts an explicit locale, detailed formatting options, and works consistently across all modern browsers.

El Unix timestamp comienza el 1 de enero de 1970 a las 00:00:00 UTC — una fecha elegida arbitrariamente por Ken Thompson y Dennis Ritchie en Bell Labs cuando desarrollaban Unix a finales de la década de 1960. Cuando escribes `time()` en PHP, `Date.now()` en JavaScript o `datetime.now().timestamp()` en Python, el número que obtienes es la cantidad de segundos o milisegundos transcurridos desde ese momento. Durante décadas, este contador se almacenó como un entero de 32 bits con signo, lo que significa que desbordará el 19 de enero de 2038 a las 03:14:07 UTC — el Y2K38, el Problema del Año 2038. Los sistemas de 64 bits resuelven esto: un entero de 64 bits puede contener aproximadamente 292.000 millones de años, mucho más allá del ciclo de vida de cualquier software en producción.

La gran ventaja del Unix timestamp es que es no ambiguo por definición. Una fecha como `01/02/2025` puede significar el 1 de febrero o el 2 de enero según el locale del sistema. Un timestamp como `1748180200` es un único punto en el tiempo, idéntico en Tokio, Nueva York o Buenos Aires. Además, los timestamps son trivialmente ordenables — comparar dos enteros es más rápido y sencillo que parsear y comparar cadenas de fecha. Un detalle que genera bugs con frecuencia: `10 dígitos = segundos`, `13 dígitos = milisegundos`. Confundirlos es un error clásico: pasar milisegundos donde el código espera segundos da como resultado una fecha equivalente al año 57.000, mientras que pasar segundos donde se esperan milisegundos produce fechas en 1970.

La regla de oro al trabajar con timestamps es: almacena siempre en UTC, convierte solo en el momento de mostrar. Esto evita toda una categoría de bugs relacionados con el horario de verano, cambios de zona horaria y diferencias de configuración entre servidores. En JavaScript, `new Date(timestamp * 1000)` crea un objeto `Date` a partir de un timestamp en segundos — el `* 1000` convierte a milisegundos, que es lo que espera el constructor. Para mostrar fechas de forma localizada y accesible, el moderno `Intl.DateTimeFormat` es superior al antiguo `toLocaleDateString()`: acepta un locale explícito, opciones de formato detalladas y funciona de manera consistente en todos los navegadores modernos.