Unix Timestamp: qué es, conversión y almacenamiento en desarrollo móvil

¿Qué es Unix Timestamp?

Unix Timestamp (también conocido como POSIX time, Epoch time o Unix time) es un sistema de medición de tiempo que define la cantidad de segundos transcurridos desde el 1 de enero de 1970 a las 00:00:00 UTC (la época Unix). Esta fecha fue elegida como punto de partida para el sistema operativo Unix, y posteriormente el formato se convirtió en el estándar de facto para representar el tiempo en sistemas informáticos. El timestamp no tiene en cuenta los segundos intercalares — cada minuto se considera de 60 segundos, aunque el Servicio Internacional de Rotación de la Tierra a veces añade un segundo adicional para corregir el tiempo atómico.

La época Unix: ¿por qué 1970?

La elección del 1 de enero de 1970 está relacionada con la historia del sistema operativo Unix. Los desarrolladores Ken Thompson y Dennis Ritchie seleccionaron esta fecha como un punto de inicio redondo y simple — era lo suficientemente temprana para abarcar todas las fechas posibles, y lo suficientemente tardía para que el tiempo pudiera almacenarse en un entero con signo de 32 bits. Inicialmente, el tiempo se medía en sesentavos de segundo, luego en ticks (1/60 de segundo), y solo en la Séptima Edición de Unix (V7, 1979) el formato se estabilizó como un número entero de segundos. Según The Open Group Base Specifications (Issue 8, 2024), los sistemas compatibles con POSIX deben soportar este formato.

Cómo funciona Unix Timestamp

El principio de funcionamiento de Unix Timestamp se basa en un contador simple: cada día que pasa añade 86 400 segundos al valor. Por ejemplo, el timestamp 1 720 000 000 corresponde a una fecha a mediados de 2024 — la conversión exacta se puede realizar dividiendo por la cantidad de segundos en un día, hora y minuto. Este enfoque hace que el timestamp sea ideal para el almacenamiento en máquinas: es un número entero que ocupa 4 bytes (int de 32 bits) u 8 bytes (long de 64 bits) y admite comparación directa — un timestamp mayor = una fecha más tardía.

Matemáticas de conversión

Un día = 86 400 segundos (24 x 60 x 60). Una hora = 3600 segundos. Para convertir un timestamp en una fecha, hay que calcular secuencialmente el número de días, horas, minutos y segundos desde la época. La conversión inversa — convertir una fecha en días desde 1970-01-01, luego multiplicar por 86 400 y sumar el desfase de UTC. En Java y Kotlin, estos cálculos ya están implementados en las clases estándar java.time.Instant y java.util.Date, lo que evita al desarrollador realizar cálculos manuales.

        // Obtener Unix Timestamp en segundos
val seconds = System.currentTimeMillis() / 1000

// Convertir timestamp a fecha mediante java.time
val instant = Instant.ofEpochSecond(seconds)
val localDate = instant.atZone(ZoneId.of("Europe/Moscow")).toLocalDate()

// Inverso: fecha a timestamp
val date = LocalDate.of(2026, 7, 21)
val ts = date.atStartOfDay(ZoneOffset.UTC).toEpochSecond()

Conversión de Unix Timestamp a fecha y viceversa

La conversión de Unix Timestamp a una fecha legible para humanos es una de las operaciones más comunes en el desarrollo móvil. En Android, hay varios métodos de conversión disponibles según la versión mínima de API: para API 26+ se recomienda usar java.time.Instant, para versiones antiguas se usan java.util.Date y java.text.SimpleDateFormat. Es importante recordar que Android y la JVM utilizan milisegundos por defecto, no segundos — si el timestamp se recibe del servidor en segundos, debe multiplicarse por 1000 antes de pasarlo a los constructores estándar.

Conversión con zona horaria

Una de las principales ventajas de Unix Timestamp es la independencia de la ubicación. El servidor siempre devuelve el timestamp en UTC, y la conversión a la fecha y hora local se realiza en el lado del cliente. En Kotlin, se utiliza ZonedDateTime con el ZoneId apropiado — el del sistema o el seleccionado por el usuario. Si una aplicación muestra la hora en diferentes zonas horarias (por ejemplo, para viajeros), el timestamp elimina la necesidad de pasar la zona horaria desde el servidor — una única marca de tiempo es suficiente.

// Convertir con zona horaria del usuario
fun formatTimestamp(seconds: Long, zoneId: ZoneId): String {
    val instant = Instant.ofEpochSecond(seconds)
    val formatter = DateTimeFormatter
        .ofPattern("dd.MM.yyyy HH:mm:ss")
    return formatter.format(instant.atZone(zoneId))
}

// Ejemplo: timestamp = 1720000000, zone = Europe/Moscow
val result = formatTimestamp(1720000000, ZoneId.of("Europe/Moscow"))

El problema del año 2038

El problema del año 2038 (Y2K38) es una limitación fundamental de almacenar Unix Timestamp como un entero con signo de 32 bits. El valor máximo de un int con signo de 32 bits es 2 147 483 647, que corresponde al 19 de enero de 2038 a las 03:14:07 UTC. Después de esta fecha, el valor se desborda y se convierte en un número negativo, causando fallos en sistemas que usan time_t de 32 bits. El problema es similar al conocido Y2K, pero afecta principalmente a sistemas embebidos, versiones antiguas de Android y dispositivos IoT con arquitectura de 32 bits.

Escala del problema

Según la Linux Foundation (2025), alrededor del 15% de los dispositivos Linux en los segmentos industrial y de IoT todavía utilizan compilaciones de 32 bits. Para los dispositivos Android, el riesgo es menor — la mayoría de los smartphones modernos funcionan con procesadores de 64 bits (ARM64), pero los modelos antiguos con Android 4.x e inferiores pueden usar time_t de 32 bits. La solución es la migración a time_t de 64 bits, que es seguro hasta 292 mil millones de años. A partir de Android 5.0 (API 21), todos los dispositivos usan tiempo de 64 bits a nivel de kernel. Los desarrolladores de aplicaciones móviles solo necesitan almacenar el timestamp como Long (64 bits) para evitar el problema a nivel de aplicación.

Trabajar con Unix Timestamp en Android

En el desarrollo de Android, el manejo correcto de Unix Timestamp es fundamental para la sincronización de datos, la visualización de las horas de recepción de mensajes, el cálculo de tiempos de espera y la programación de notificaciones. La llamada al sistema System.currentTimeMillis() devuelve la hora actual en milisegundos desde la época Unix — esta es la fuente de tiempo más precisa disponible en el dispositivo. Para las solicitudes de red, se suele usar Unix Timestamp en segundos, ya que la mayoría de las API REST y bases de datos operan en segundos.

Prácticas recomendadas

Nunca use System.currentTimeMillis() para medir intervalos — para este propósito existe System.nanoTime(), que es monotónica y no se ve afectada por los cambios de hora del usuario. Para mostrar la hora, almacene siempre el timestamp en UTC y conviértalo a la zona horaria local en el lado de la interfaz de usuario. Al trabajar con bases de datos (SQLite, Room), use el tipo INTEGER y almacene el timestamp en segundos — esto ocupa 8 bytes (Long) y admite la ordenación nativa de SQL. Para la serialización JSON, se recomienda enviar el timestamp como un número (Long) en lugar de una cadena — es más compacto y se analiza más rápido.

// Medición correcta del tiempo de ejecución
val start = System.nanoTime()
// ... operación ...
val elapsed = System.nanoTime() - start
val seconds = elapsed / 1_000_000_000.0

// Almacenar en Room (Entity)
@Entity
data class Message(
    @PrimaryKey val id: Long,
    val text: String,
    val createdAt: Long // Unix Timestamp en segundos
)

Manejo de la hora del servidor

Al recibir un Unix Timestamp del servidor, siempre verifique la unidad de medida: algunas API devuelven milisegundos (compatibles con JavaScript), otras devuelven segundos (estándar POSIX). El acuerdo sobre las unidades debe estar documentado en la especificación de la API. En la respuesta del servidor, el timestamp se puede pasar como Long (número JSON) o String (ISO 8601). Para la depuración, añada una función de utilidad que muestre el timestamp en un formato legible para humanos — esto simplifica la verificación de las marcas de tiempo durante el desarrollo.

Almacenamiento de marcas de tiempo en bases de datos

La elección del formato de almacenamiento de tiempo en una base de datos afecta directamente al rendimiento de las consultas, la complejidad del código y la corrección del manejo de zonas horarias. Unix Timestamp es el formato más eficiente para bases de datos relacionales: se almacena como un número entero (4 u 8 bytes), admite indexación y permite una ordenación rápida. A diferencia de las cadenas ISO 8601, el timestamp no requiere análisis para la ordenación y ocupa menos espacio en un índice. Para Room y SQLite, se recomienda almacenar el timestamp como INTEGER y usar un índice en la columna de tiempo.

Recomendaciones para proyectos móviles

Para aplicaciones Android con la biblioteca Room, se recomienda almacenar los timestamps como Long (64 bits) y usar un TypeConverter para la conversión automática entre Long y Date o Instant. Al realizar consultas a la base de datos, use operadores de comparación (>, <, BETWEEN) — funcionan de forma nativa con tipos enteros. Para almacenar en caché datos que requieren ordenación por tiempo (por ejemplo, una lista de mensajes), cree siempre un índice en la columna de timestamp — esto acelerará las consultas con ORDER BY en varios órdenes de magnitud con grandes volúmenes de datos.