Unix Timestamp Converter

What a Unix timestamp is

A Unix timestamp — also called epoch time, POSIX time or Unix time — is the number of seconds that have passed since 1970-01-01 00:00:00 UTC, the Unix epoch. It ignores leap seconds, so every day is exactly 86,400 seconds. Because it is a single integer with no time zone attached, it is the usual way to store and compare instants in databases, logs, JWT claims, cron schedulers and APIs.

The number is the same everywhere on Earth at a given moment. What changes by location is only how it is displayed: 1790000000 is 2026-09-21 14:13:20 in UTC and 2026-09-21 19:43:20 in India Standard Time. That is why the converter above shows several zones side by side instead of guessing one.

Seconds, milliseconds, microseconds or nanoseconds?

Different platforms count the same instant with different precision. The quickest way to tell them apart is the number of digits in a present-day value:

Auto-detect uses exactly this rule (up to 11 digits → seconds, 12–14 → milliseconds, 15–17 → microseconds, 18+ → nanoseconds). If you feed a millisecond value to a function that expects seconds you get a date around the year 58,000; the reverse gives a date in January 1970 — both are tell-tale signs of a unit mix-up.

Convert epoch time to IST (India Standard Time)

IST is a fixed UTC+05:30 with no daylight saving time, so converting an epoch timestamp to IST is always “UTC plus 19,800 seconds”. Midnight IST is 18:30 UTC on the previous day, which is the most common source of off-by-one-day bugs in Indian reports built from UTC timestamps. Choose Asia/Kolkata in the selector, or read the IST row that the converter always shows. If you schedule AWS jobs in UTC, the AWS cron to IST converter does the same shift for cron expressions.

Epoch reference table

Boundaries for the current period, computed live in the time zone you selected above (your local zone). Weeks start on Monday, following ISO 8601.

Notable Unix timestamps

Durations in seconds

How to get the current epoch time in code

Each snippet prints the current Unix timestamp and then converts a timestamp back to a date.

JavaScript

Math.floor(Date.now() / 1000);          // seconds  (Date.now() is milliseconds)
new Date(1790000000 * 1000).toISOString(); // "2026-09-21T14:13:20.000Z"
new Date(1790000000 * 1000).toLocaleString("en-IN", { timeZone: "Asia/Kolkata" });

Python

import time, datetime
int(time.time())                      # seconds
time.time_ns()                        # nanoseconds
datetime.datetime.fromtimestamp(1790000000, datetime.timezone.utc)
# datetime.datetime(2026, 9, 21, 14, 13, 20, tzinfo=datetime.timezone.utc)
from zoneinfo import ZoneInfo
datetime.datetime(2026, 9, 24, 15, 30, tzinfo=ZoneInfo("Asia/Kolkata")).timestamp()

Java

long seconds = java.time.Instant.now().getEpochSecond();
long millis  = System.currentTimeMillis();
java.time.Instant.ofEpochSecond(1790000000L)
    .atZone(java.time.ZoneId.of("Asia/Kolkata"));   // 2026-09-21T19:43:20+05:30[Asia/Kolkata]

Go

now := time.Now()
now.Unix()      // seconds
now.UnixMilli() // milliseconds
now.UnixNano()  // nanoseconds
time.Unix(1790000000, 0).UTC().Format(time.RFC3339) // "2026-09-21T14:13:20Z"

PHP

time();                                  // seconds
date('Y-m-d H:i:s', 1790000000);          // in the default timezone
(new DateTime('@1790000000'))->setTimezone(new DateTimeZone('Asia/Kolkata'))->format(DATE_RFC2822);

MySQL

SELECT UNIX_TIMESTAMP();                          -- current epoch seconds
SELECT FROM_UNIXTIME(1790000000);                 -- in the session time_zone
SELECT UNIX_TIMESTAMP('2026-09-24 15:30:00');     -- session time_zone applies

PostgreSQL

SELECT extract(epoch FROM now())::bigint;          -- current epoch seconds
SELECT to_timestamp(1790000000);                   -- timestamptz
SELECT to_timestamp(1790000000) AT TIME ZONE 'Asia/Kolkata';

Bash / Linux / macOS

date +%s                          # seconds
date +%s%3N                       # milliseconds (GNU date)
date -u -d @1790000000            # GNU/Linux: epoch to date
date -u -r 1790000000             # macOS/BSD: epoch to date
TZ=Asia/Kolkata date -d @1790000000
date -d '2026-09-24 15:30:00 IST' +%s   # date to epoch (GNU)

PowerShell

[DateTimeOffset]::UtcNow.ToUnixTimeSeconds()
[DateTimeOffset]::FromUnixTimeSeconds(1790000000).UtcDateTime

The year 2038 problem

Older C programs, embedded firmware and some database columns store Unix time in a signed 32-bit integer. The largest value it can hold is 2147483647 — 2038-01-19 03:14:07 UTC (08:44:07 IST). One second later the counter wraps to -2147483648, which reads as 13 December 1901. Linux on 64-bit hardware, JavaScript (which uses 64-bit floats for milliseconds), Java long and PostgreSQL timestamptz are safe. Watch out for MySQL TIMESTAMP columns (limited to 2038 in versions before 8.0.28) and any INT column you use to store epoch seconds — use BIGINT or DATETIME instead.

ISO 8601 vs RFC 2822 vs Unix time

For machine-to-machine exchange, ISO 8601 (2026-09-24T15:30:00+05:30) is readable and sorts correctly as text; RFC 2822 (Thu, 24 Sep 2026 15:30:00 +0530) is what email headers and HTTP Date use; Unix time is smallest and fastest to compare. Store instants as UTC (epoch or ISO with Z) and convert to a local zone only for display. To turn an ISO 8601 string into epoch time, paste it (for example 2026-09-24T10:00:00Z or 2026-09-24T15:30:00+05:30) into Date to Unix timestamp; the offset in the string is respected.

Common questions