Qué representa el timestamp Unix 0
Cada timestamp Unix cuenta el tiempo transcurrido desde un único punto de referencia: el 1 de enero de 1970 a las 00:00:00 UTC. En la definición original de Unix la unidad es el segundo, así que el timestamp 0 es exactamente la medianoche UTC del 1 de enero de 1970, y el timestamp 86400 es exactamente 24 horas después. Los sistemas modernos también usan milisegundos, microsegundos y nanosegundos, pero el punto de referencia es el mismo. Cada valor positivo representa un momento posterior al epoch; cada valor negativo, uno anterior.
¿Por qué el 1 de enero de 1970?
La fecha la eligieron los desarrolladores de Unix en Bell Labs a principios de los años setenta como un punto de referencia práctico, poco anterior a la creación del propio Unix. Tenía que ser lo bastante temprana para que los timestamps normales del sistema fueran positivos, lo bastante reciente para caber en los pequeños rangos de enteros de los primeros ordenadores, y lo bastante simple de verificar mentalmente. Cuando Unix se volvió influyente, los lenguajes, sistemas operativos, bases de datos, formatos de log y protocolos de red heredaron el mismo punto de partida.
- Unix se desarrolló en Bell Labs a partir de 1969 — el epoch se fijó justo antes
- Se eligió el 1 de enero como límite de calendario limpio
- 1970 en vez de 1969 porque la implementación usaba un contador que empezaba en cero
- Todos los SO, lenguajes y protocolos modernos heredaron este epoch — no hay un estándar rival
Timestamps negativos: fechas anteriores a 1970
Los timestamps Unix negativos representan momentos anteriores al 1 de enero de 1970 00:00:00 UTC. La mayoría de los sistemas modernos de 64 bits los admiten correctamente, lo que es útil para datos históricos, fechas de nacimiento, registros de archivo e interoperabilidad con sistemas cuyos epochs empiezan antes que el de Unix. Las librerías y bases de datos antiguas pueden rechazar valores negativos, así que los conjuntos de datos históricos merecen una comprobación explícita de compatibilidad.
- -1 = December 31, 1969 23:59:59 UTC (one second before the epoch)
- -86400 = December 31, 1969 00:00:00 UTC (one day before the epoch)
- -2208988800 = January 1, 1900 00:00:00 UTC
- JavaScript: new Date(-86400 * 1000).toISOString() → '1969-12-31T00:00:00.000Z'
Límites prácticos del formato
El epoch Unix en sí no es el límite; lo es el tipo de almacenamiento. Un timestamp guardado en un entero con signo de 32 bits falla mucho antes que uno guardado en un entero de 64 bits, un número de JavaScript o un tipo de timestamp nativo de base de datos. Al evaluar la seguridad de un timestamp, pregunta tanto qué unidad se usa como qué tipo numérico lo almacena.
- 32-bit signed integer max: 2,147,483,647 = January 19, 2038 03:14:07 UTC (the Year 2038 problem)
- JavaScript Date max: 8,640,000,000,000,000 ms = September 13, 275760 CE
- 64-bit signed integer max: ~9.2 × 10^18 seconds = year ~292 billion
- PostgreSQL TIMESTAMPTZ max: January 1, 294276 CE
Los epochs de otros sistemas
Unix no es el único epoch usado en informática. Otros sistemas definieron sus propios puntos de referencia por razones históricas o técnicas.
- Epoch de GPS: 6 de enero de 1980 00:00:00 UTC — usado por satélites y receptores GPS
- Windows FILETIME: 1 de enero de 1601 00:00:00 UTC — intervalos de 100 nanosegundos
- Apple Cocoa / NSDate: 1 de enero de 2001 00:00:00 UTC
- Excel / Lotus 1-2-3: 1 de enero de 1900 — con un error deliberado de año bisiesto por compatibilidad con Lotus
- Sistema de archivos FAT: 1 de enero de 1980 00:00:00 hora local
Segundos, milisegundos, microsegundos y nanosegundos epoch
La palabra timestamp no siempre indica la unidad. Los segundos Unix son comunes en sistemas operativos y lenguajes de backend. Los milisegundos Unix son comunes en JavaScript y las APIs del navegador. Los microsegundos y nanosegundos aparecen en bases de datos, sistemas de trazas y logs de alta resolución. La unidad controla tanto la precisión como el número de dígitos que ves.
- Seconds: 1700000000 — common in Python, PHP, Go, Ruby, C, and Unix command-line tools
- Milliseconds: 1700000000000 — common in JavaScript Date and many web analytics systems
- Microseconds: 1700000000000000 — common in some databases and event pipelines
- Nanoseconds: 1700000000000000000 — common in high-resolution tracing and systems languages
- Always document the unit when storing epoch values in APIs, CSV files, and database columns
Tiempo epoch vs UTC vs hora local
El tiempo epoch es un recuento. UTC es el estándar global de tiempo que define el momento de referencia. La hora local es una elección de visualización basada en una zona horaria como America/New_York o Asia/Tokyo. Un timestamp Unix no cambia cuando un usuario viaja; solo cambian la fecha de calendario y la hora formateadas.
- El mismo timestamp puede mostrarse como fechas locales distintas en zonas horarias distintas
- La salida UTC es mejor para logs, APIs y depuración entre servidores
- La salida local es mejor para calendarios, interfaces e informes
- Los desfases de zona horaria se aplican al formatear, no se guardan dentro del timestamp Unix
Preguntas frecuentes sobre el tiempo epoch
The Unix epoch (1970-01-01 UTC) was inherited from Multics, the OS that influenced early Unix design. POSIX later standardized the time_t type with explicit semantics that differ from how the original Unix specs described it — and most other platforms count from a different epoch entirely.
- Multics (1969) counted seconds from 1970-01-01 GMT; Unix adopted the same epoch in 1971
- POSIX time_t is defined as a count of seconds since 1970 UTC, explicitly excluding leap seconds (every day is 86,400 ticks)
- POSIX vs Unix terminology: in practice the two are used interchangeably; POSIX is the standardized name
- Other software epochs differ widely:
- Windows FILETIME — 1601-01-01 UTC (Gregorian-cycle start), 100-nanosecond intervals
- .NET DateTime.Ticks — 0001-01-01, 100-nanosecond intervals
- Apple / Core Data — 2001-01-01 UTC (Cocoa reference date), seconds
- NTP — 1900-01-01 UTC, seconds; GPS — 1980-01-06, seconds (no leap seconds)
- Julian Day — noon UT, 4713 BC (proleptic Julian), days
- When importing time data, confirm the epoch before trusting the value as Unix time
Related articles
FAQ
- Is epoch time always in seconds?
- The classic Unix timestamp is seconds since 1970-01-01 00:00:00 UTC, but many systems use milliseconds, microseconds, or nanoseconds with the same epoch.
- Can Unix timestamps represent dates before 1970?
- Yes. Negative timestamps represent dates before the Unix epoch, though older libraries and databases may not support them.
- Does a Unix timestamp include a timezone?
- No. A Unix timestamp represents one instant in UTC. Timezone information is used only when converting that instant into a readable local date.
- What is the maximum Unix timestamp?
- It depends on the storage type, not the epoch. A 32-bit signed integer maxes out at 2,147,483,647 (January 19, 2038), while a 64-bit integer or a JavaScript number reaches hundreds of millions of years. See the Year 2038 problem for the details.