Convert epoch time to dates and vice versa. Supports timezones, milliseconds, and batch conversion.
Unix time (epoch time) is the number of seconds since January 1, 1970 00:00:00 UTC. This converter turns timestamps into human-readable dates and vice versa. Use it when working with APIs, databases, or logs that store times as numbers. It handles seconds, milliseconds, microseconds, and nanoseconds, and shows conversions across common timezones. Use the Unix Timestamp Converter to get a clear result you can act on right away. This calculator is designed to be practical, fast, and easy to use on any device. If you are comparing options, run a few scenarios to see how small changes affect the outcome.
Wednesday, January 1, 2025 at 12:00:00 AM
Unix: 1735689600 (seconds)
UTC
Wednesday, January 1, 2025 at 12:00:00 AM
New York (EST/EDT)
Tuesday, December 31, 2024 at 7:00:00 PM
Los Angeles (PST/PDT)
Tuesday, December 31, 2024 at 4:00:00 PM
London (GMT/BST)
Wednesday, January 1, 2025 at 12:00:00 AM
Tokyo (JST)
Wednesday, January 1, 2025 at 9:00:00 AM
Sydney (AEDT/AEST)
Wednesday, January 1, 2025 at 11:00:00 AM
Relative time
16 months ago
ISO 8601
2025-01-01T00:00:00.000Z
RFC 2822
Wed, 01 Jan 2025 00:00:00 GMT
What is a Unix timestamp?
A Unix timestamp is the number of seconds since Jan 1, 1970 (UTC).
If your date appears as 1969 or 1970, it usually means your timestamp is incorrect. This commonly happens when:
If you ever see a date like:
It almost always means your Unix timestamp is wrong (or missing).
Unix time starts at January 1, 1970 (00:00:00 UTC) - the Unix epoch.
When something goes wrong, your code often falls back to:
new Date(1716153600) // Wrong - treated as millisecondsThis produces a date near 1970.
Correct:
new Date(1716153600 * 1000)JavaScript's Date expects milliseconds, not seconds.
new Date(undefined)Often results in 1970 or "Invalid Date".
new Date("bad-data")Fallback behavior can default to the epoch.
For example: the API sends seconds but the frontend expects milliseconds - dates land near 1970.
new Date(-1000)Returns Dec 31, 1969 - valid for pre-epoch times, but often unintended.
If you see 1969 or 1970, check this immediately:
You expect 1716153600 → 2024, but you write:
new Date(1716153600)Result: around January 20, 1970 (UTC) - because the value was treated as milliseconds, not seconds. Fix: multiply by 1000 when building the Date.
Example timestamp used: 1716153600 → May 19, 2024 (UTC)
const timestamp = 1716153600;
const date = new Date(timestamp * 1000);
console.log(date.toUTCString());from datetime import datetime
timestamp = 1716153600
date = datetime.utcfromtimestamp(timestamp)
print(date)import java.time.Instant;
import java.time.ZoneId;
import java.time.ZonedDateTime;
long timestamp = 1716153600L;
ZonedDateTime date = Instant.ofEpochSecond(timestamp).atZone(ZoneId.of("UTC"));
System.out.println(date);using System;
long timestamp = 1716153600;
DateTime date = DateTimeOffset.FromUnixTimeSeconds(timestamp).UtcDateTime;
Console.WriteLine(date);package main
import (
"fmt"
"time"
)
func main() {
timestamp := int64(1716153600)
date := time.Unix(timestamp, 0).UTC()
fmt.Println(date)
}<?php
$timestamp = 1716153600;
echo gmdate("Y-m-d H:i:s", $timestamp);
?>timestamp = 1716153600
date = Time.at(timestamp).utc
puts dateimport Foundation
let timestamp: TimeInterval = 1716153600
let date = Date(timeIntervalSince1970: timestamp)
print(date)import java.time.Instant
import java.time.ZoneOffset
val timestamp = 1716153600L
val date = Instant.ofEpochSecond(timestamp).atOffset(ZoneOffset.UTC)
println(date)use chrono::{TimeZone, Utc};
let timestamp = 1716153600;
let date = Utc.timestamp_opt(timestamp, 0).unwrap();
println!("{}", date);#include <stdio.h>
#include <time.h>
int main() {
time_t timestamp = 1716153600;
printf("%s", asctime(gmtime(×tamp)));
return 0;
}#include <iostream>
#include <ctime>
int main() {
std::time_t timestamp = 1716153600;
std::cout << std::asctime(std::gmtime(×tamp));
return 0;
}date -u -d @1716153600$timestamp = 1716153600
$date = [DateTimeOffset]::FromUnixTimeSeconds($timestamp).UtcDateTime
Write-Output $dateSELECT to_timestamp(1716153600);SELECT FROM_UNIXTIME(1716153600);timestamp <- 1716153600
date <- as.POSIXct(timestamp, origin="1970-01-01", tz="UTC")
print(date)timestamp = 1716153600;
date = datetime(timestamp, 'ConvertFrom', 'posixtime', 'TimeZone', 'UTC');
disp(date);void main() {
int timestamp = 1716153600;
DateTime date = DateTime.fromMillisecondsSinceEpoch(timestamp * 1000, isUtc: true);
print(date);
}const timestamp: number = 1716153600;
const date: Date = new Date(timestamp * 1000);
console.log(date.toUTCString());Common Gotcha
Quick Rule
A Unix timestamp is the number of seconds that have elapsed since January 1, 1970 (00:00:00 UTC), also known as the Unix epoch. It is used by computers to store and track time in a simple numeric format that is easy to calculate and compare.
Unix timestamps are widely used because they are:
They are commonly used in programming, databases, logging systems, and APIs.
To convert a Unix timestamp:
Example: 1716153600 → May 19, 2024 (UTC)
You can use the converter on this page to instantly convert timestamps in both directions.
Unix timestamps can be stored in different units:
Key difference:
If your timestamp has 13 digits, divide by 1000 to convert to seconds.
Yes. Unix timestamps are always based on UTC (Coordinated Universal Time).
This ensures consistency across systems worldwide.
Yes. Negative Unix timestamps represent dates before January 1, 1970.
Example: -1 → December 31, 1969 (UTC)
This is useful for historical dates and certain database systems.
The 2038 problem is a limitation in older 32-bit systems where Unix timestamps will overflow on:
January 19, 2038 at 03:14:07 UTC
This happens because the timestamp exceeds the maximum value a 32-bit signed integer can store.
Modern systems use 64-bit integers, which solve this issue.
Common causes include:
Always check the number of digits:
Unix timestamps are commonly used in:
They provide a consistent and efficient way to handle time across systems.
Unix timestamps are better for computation, while ISO 8601 is better for readability.
No. Unix timestamps are based entirely on UTC, so they are not affected by daylight saving time (DST).
DST only affects how timestamps are displayed in local timezones.
Standard Unix timestamps are accurate to seconds, but they can also be stored in:
Higher precision is used in systems that require exact timing, such as financial systems or high-performance computing.