Conversor de fecha Unix: de timestamp a fecha y hora, con zonas horarias

Escribe una fecha Unix (timestamp) y la herramienta la convierte a fecha y hora en la zona horaria que elijas, en ISO 8601 y en el formato de las cabeceras HTTP. Detecta sola si el número está en segundos, milisegundos, microsegundos o nanosegundos. También funciona al revés: escribe una fecha como 2027-01-15 08:00 y obtendrás su fecha Unix. Todo se calcula en tu navegador.

Qué es la fecha Unix

La fecha Unix (también epoch o timestamp) es el número de segundos que han pasado desde el 1 de enero de 1970 a las 00:00:00 UTC. Es la forma más común de guardar un instante en programas, bases de datos y registros, porque es un número entero, no depende de la zona horaria y se compara y se resta sin complicaciones: el mismo instante tiene la misma fecha Unix en Ciudad de México, en Madrid y en Tokio.

Las fechas anteriores a 1970 son negativas. La fecha Unix no cuenta los segundos intercalares: todos los días tienen exactamente 86 400 segundos.

Segundos, milisegundos, microsegundos y nanosegundos

Cada sistema usa una unidad: Unix y PHP cuentan en segundos; JavaScript y Java, en milisegundos; algunas bases de datos y registros, en microsegundos o nanosegundos. Como las fechas actuales tienen un número de cifras muy distinto en cada unidad, la herramienta las distingue por su longitud:

La regla acierta con cualquier fecha entre 1973 y el año 5138. Con fechas más antiguas, o con números pequeños que no son fechas, elige la unidad a mano.

El problema del año 2038

Muchos sistemas antiguos guardan la fecha Unix en un entero de 32 bits con signo, cuyo valor máximo es 2147483647: el 2038-01-19T03:14:07Z. Un segundo después, el contador se desborda y pasa a -2147483648, que es el 1901-12-13T20:45:52Z. Los sistemas actuales usan 64 bits y no tienen el problema, pero aún quedan programas, formatos de archivo y columnas de bases de datos de 32 bits. Pruébalo con el botón «El límite de 2038».

Zonas horarias y cambios de horario

La herramienta usa la base de datos de zonas horarias de tu navegador (la de la IANA, la misma que usan los sistemas operativos), con todos sus cambios históricos. Por ejemplo, sabe que México dejó el horario de verano en 2022, salvo en los municipios de la frontera norte, que siguen el de Estados Unidos.

Cuando conviertes una fecha sin zona escrita, se interpreta en la zona elegida, y ahí hay dos casos especiales. Si ese día el reloj se adelanta, hay horas que no existen; si se atrasa, hay horas que ocurren dos veces. La herramienta avisa de ambos: en la hora repetida da los dos instantes, y en la que no existe aplica el desplazamiento de antes del cambio, como hacen Python y Java.

La fecha Unix en cada lenguaje

Cómo obtener la fecha Unix actual y convertir 1800000000 (el 2027-01-15T08:00:00Z) en ambos sentidos. Las salidas son reales; la primera línea de cada una es la hora en que se ejecutó.

Python

import time
from datetime import datetime, timezone
from zoneinfo import ZoneInfo  # en Windows: pip install tzdata

print(int(time.time()))  # ahora, en segundos

ts = 1800000000
print(datetime.fromtimestamp(ts, tz=timezone.utc).isoformat())
print(datetime.fromtimestamp(ts, tz=ZoneInfo("America/Mexico_City")).isoformat())

fecha = datetime(2027, 1, 15, 2, 0, tzinfo=ZoneInfo("America/Mexico_City"))
print(int(fecha.timestamp()))

$ python3 fechas.py1791873555
2027-01-15T08:00:00+00:00
2027-01-15T02:00:00-06:00
1800000000

time.time() devuelve segundos con decimales. Pasa siempre la zona (tz=): sin ella, fromtimestamp usa la del equipo y datetime queda «ingenua», sin zona, que es la causa de muchos errores.

JavaScript

console.log(Math.floor(Date.now() / 1000)); // ahora, en segundos

const ts = 1800000000;
const fecha = new Date(ts * 1000); // Date trabaja en milisegundos
console.log(fecha.toISOString());
console.log(fecha.toLocaleString("es-MX", { timeZone: "America/Mexico_City" }));
console.log(Date.UTC(2027, 0, 15, 8, 0) / 1000); // ¡los meses empiezan en 0!

$ node fechas.js1791873555
2027-01-15T08:00:00.000Z
15/1/2027, 2:00:00 a.m.
1800000000

Date trabaja en milisegundos: hay que multiplicar o dividir por 1000. Y en Date.UTC los meses empiezan en 0, así que enero es 0.

Java

import java.time.*;

void main() {
    IO.println(Instant.now().getEpochSecond()); // ahora, en segundos

    Instant instante = Instant.ofEpochSecond(1_800_000_000L);
    IO.println(instante);
    IO.println(instante.atZone(ZoneId.of("America/Mexico_City")));

    ZonedDateTime fecha = ZonedDateTime.of(2027, 1, 15, 2, 0, 0, 0, ZoneId.of("America/Mexico_City"));
    IO.println(fecha.toEpochSecond());
}

$ java Unix.java1791873556
2027-01-15T08:00:00Z
2027-01-15T02:00-06:00[America/Mexico_City]
1800000000

java.time distingue el instante (Instant) de la fecha en una zona (ZonedDateTime). El ejemplo usa la forma compacta de Java 25, sin clase.

Go

package main

import (
	"fmt"
	"time"
)

func main() {
	fmt.Println(time.Now().Unix()) // ahora, en segundos

	t := time.Unix(1800000000, 0)
	fmt.Println(t.UTC().Format(time.RFC3339))
	mx, err := time.LoadLocation("America/Mexico_City")
	if err != nil {
		panic(err)
	}
	fmt.Println(t.In(mx).Format(time.RFC3339))
	fmt.Println(time.Date(2027, 1, 15, 2, 0, 0, 0, mx).Unix())
}

$ go run unix.go1791873559
2027-01-15T08:00:00Z
2027-01-15T02:00:00-06:00
1800000000

time.Unix(seg, nanoseg) crea el instante; UnixMilli y UnixNano dan las otras unidades.

Rust

use std::time::{SystemTime, UNIX_EPOCH};

fn main() {
    let ahora = SystemTime::now()
        .duration_since(UNIX_EPOCH)
        .expect("el reloj marca una fecha anterior a 1970");
    println!("{}", ahora.as_secs()); // ahora, en segundos
    println!("{}", ahora.as_millis()); // en milisegundos
}

$ rustc unix.rs && ./unix1791873560
1791873560338

La biblioteca estándar da la duración desde 1970, pero no tiene calendario: para convertir a fecha y hora con zonas se usa un crate como jiff o chrono.

Bash (GNU date)

$ date +%s
1791873560
$ date -u -d @1800000000
Fri Jan 15 08:00:00 UTC 2027
$ TZ=America/Mexico_City date -d @1800000000 '+%F %T %Z'
2027-01-15 02:00:00 CST
$ date -d '2027-01-15 08:00 UTC' +%s
1800000000

En macOS, date es la versión BSD: la conversión se escribe date -r 1800000000.

PostgreSQL

SELECT extract(epoch FROM now())::bigint AS ahora;
SELECT to_timestamp(1800000000) AT TIME ZONE 'UTC' AS utc;
SELECT to_timestamp(1800000000) AT TIME ZONE 'America/Mexico_City' AS mexico;
SELECT extract(epoch FROM timestamptz '2027-01-15 02:00 America/Mexico_City')::bigint AS ts;

$ psql -f fechas.sql   ahora    
------------
 1791873514
(1 row)

         utc         
---------------------
 2027-01-15 08:00:00
(1 row)

       mexico        
---------------------
 2027-01-15 02:00:00
(1 row)

     ts     
------------
 1800000000
(1 row)

MySQL

SET time_zone = '+00:00';
SELECT UNIX_TIMESTAMP() AS ahora;
SELECT FROM_UNIXTIME(1800000000) AS utc;
SELECT UNIX_TIMESTAMP('2027-01-15 08:00:00') AS ts;

$ mysql --table < fechas.sql+------------+
| ahora      |
+------------+
| 1791873547 |
+------------+
+---------------------+
| utc                 |
+---------------------+
| 2027-01-15 08:00:00 |
+---------------------+
+------------+
| ts         |
+------------+
| 1800000000 |
+------------+

En MySQL, FROM_UNIXTIME y UNIX_TIMESTAMP usan la zona horaria de la sesión: por eso el ejemplo la fija en UTC antes de convertir.

Más herramientas para desarrolladores: el formateador de JSON, el decodificador de JWT y el conversor de fecha Unix. Todas, en decodigo.com/herramientas.

La conversión se comprobó contra zoneinfo de Python (tzdata 2026e) con 6 000 instantes al azar entre 1900 y 2100 y 63 311 horas de reloj alrededor de los cambios de horario de 40 zonas entre 1995 y 2035, incluidas las que no existen o se repiten. Las salidas de los ejemplos se obtuvieron el 13 de octubre de 2026 con Python 3.13.16, Node v22.23.3, Java 25, Go 1.25, Rust 1.99, GNU coreutils 9.1, PostgreSQL 17 y MySQL 8.4.