Unix Timestamp Converter
Convert between Unix seconds, milliseconds, ISO 8601 and human-readable dates in any timezone, in both directions.
Time Utility
Timezone conversion, duration, arithmetic, and format conversion — all instant, all local.
Timezone Converter
| City / Zone | Time | Date | Offset |
|---|---|---|---|
| UTC source | 12:00 | Wed, Sep 2 | GMT+0 |
| Los Angeles | 05:00 | Wed, Sep 2 | GMT-7 |
| Chicago | 07:00 | Wed, Sep 2 | GMT-5 |
| New York | 08:00 | Wed, Sep 2 | GMT-4 |
| São Paulo | 09:00 | Wed, Sep 2 | GMT-3 |
| London | 13:00 | Wed, Sep 2 | GMT+1 |
| Paris / Berlin | 14:00 | Wed, Sep 2 | GMT+2 |
| Cairo | 15:00 | Wed, Sep 2 | GMT+3 |
| Dubai | 16:00 | Wed, Sep 2 | GMT+4 |
| Mumbai / Delhi | 17:30 | Wed, Sep 2 | GMT+5:30 |
| Singapore | 20:00 | Wed, Sep 2 | GMT+8 |
| Tokyo | 21:00 | Wed, Sep 2 | GMT+9 |
| Sydney | 22:00 | Wed, Sep 2 | GMT+10 |
| Auckland | 00:00 | Thu, Sep 3 ↕ | GMT+12 |
Duration
Add / Subtract
12h ↔ 24h
Seconds or milliseconds? Count the digits
The commonest timestamp bug is a factor-of-1000 unit mismatch. Digit count identifies it instantly:
| Digits | Unit | Example | Decodes to |
|---|---|---|---|
| 10 | Seconds | 1788282000 | A date around now |
| 13 | Milliseconds | 1788282000000 | The same date |
| 16 | Microseconds | 1788282000000000 | The same date |
| 19 | Nanoseconds | 1788282000000000000 | The same date |
| — | Seconds read as ms | 1788282000 as ms | 1970 — the giveaway |
| — | Ms read as seconds | 1788282000000 as s | Year 58,669 — the other giveaway |
JavaScript uses milliseconds; almost every backend language, database and Unix tool uses seconds. That mismatch at the API boundary is where this bug lives. Python time.time() returns fractional seconds, Go uses nanoseconds internally, and Java switched to milliseconds long ago.
What Unix time actually counts
Unix time is the number of seconds since 00:00:00 UTC on 1 January 1970, not counting leap seconds.
That last clause does a lot of work. Because leap seconds are excluded, Unix time is not a count of elapsed physical seconds — it is a count of non-leap seconds, which means the value repeats or is smeared when a leap second occurs. It also means Unix time is always exactly 86,400 seconds per day by definition, which is what makes date arithmetic on it tractable.
The practical upside: a Unix timestamp is unambiguous. It has no timezone, no daylight saving, no locale and no format ambiguity. The value identifies one instant, everywhere. This is why it is the right thing to store and transmit, and why converting to local time should happen only at the display layer.
Year 2038: a signed 32-bit integer overflows at 03:14:07 UTC on 19 January 2038. Systems still using a 32-bit time_t will wrap to 1901. Most modern platforms moved to 64-bit long ago, but embedded devices, older databases and some file formats have not — and the bugs start appearing well before 2038 in anything that computes future dates, such as a 20-year mortgage schedule.
Date parsing bugs
A date is off by one day for some users
Cause:A date-only string parsed as UTC midnight then displayed in a negative-offset timezone. new Date("2026-09-01") is midnight UTC, which is 31 August in the Americas.
Fix:For a calendar date with no time component, do not convert timezones at all — treat it as a plain date. If you must use Date, parse as new Date("2026-09-01T00:00:00") without the Z to get local midnight.
Parsing works in Chrome, returns Invalid Date in Safari
Cause:Only ISO 8601 is required to parse consistently. Formats like "2026-09-01 14:30:00" (space instead of T) are implementation-defined and Safari rejects several that V8 accepts.
Fix:Always produce and parse strict ISO 8601 with a T separator and an explicit offset or Z. Never rely on a runtime parsing a loose format.
A recurring job runs twice or not at all, twice a year
Cause:Daylight saving. 01:30 local occurs twice on the day clocks go back and never on the day they go forward.
Fix:Schedule in UTC. If a job must run at a local wall-clock time, use a scheduler that understands timezones and make the job idempotent so a double run is harmless.
Storing a timezone offset instead of a timezone
Cause:"+01:00" is an offset at one instant, not a zone. It does not tell you what the offset will be next summer, so future dates computed from it are wrong.
Fix:Store the IANA zone name (Europe/London), not the offset. For future events people will attend, store the local time plus the zone, because if the government changes the rules the meeting stays at 9am.
Sorting timestamps produces the wrong order
Cause:Comparing formatted date strings rather than the underlying values. "10/09/2026" sorts before "9/09/2026" lexically.
Fix:Sort on the numeric timestamp or on ISO 8601 strings, which are designed to sort correctly as text. That is the main reason to prefer ISO format in stored data.
Working with timestamps
Date.now(); // ms since epoch
Math.floor(Date.now() / 1000); // seconds — note the floor
new Date(1788282000 * 1000); // from seconds
new Date().toISOString(); // '2026-09-01T00:00:00.000Z'
// Formatting in a specific zone, no library required
new Intl.DateTimeFormat('en-GB', {
timeZone: 'Asia/Kolkata',
dateStyle: 'medium',
timeStyle: 'short'
}).format(new Date());
// Temporal is the modern replacement for Date and fixes
// most of its design problems. Check availability before use.from datetime import datetime, timezone
# Aware, in UTC. Prefer this over utcnow(), which returns a
# naive datetime and is deprecated in 3.12+.
now = datetime.now(timezone.utc)
now.timestamp() # float seconds
datetime.fromtimestamp(1788282000, tz=timezone.utc)
now.isoformat()
# Named zones, standard library since 3.9
from zoneinfo import ZoneInfo
now.astimezone(ZoneInfo("Asia/Kolkata"))-- PostgreSQL: prefer timestamptz over timestamp.
-- timestamp stores no zone and silently means different
-- instants to different clients.
SELECT EXTRACT(EPOCH FROM now());
SELECT to_timestamp(1788282000);
-- MySQL
SELECT UNIX_TIMESTAMP(), FROM_UNIXTIME(1788282000);
-- SQLite has no date type; store ISO 8601 text or an integer
SELECT strftime('%s', 'now');About
The Time Utility bundles several time-related tools: a timezone converter that shows any time in another timezone, a duration calculator that finds the difference between two times, an add/subtract utility, and a 12-hour/24-hour format converter. All tools work offline in your browser.
How to use
- 1 Select a tab: Timezone Converter, Duration, Add/Subtract, or Format.
- 2 For Timezone Converter: enter a time, select the source and target timezones.
- 3 For Duration: enter start and end times to get the hours and minutes between them.
- 4 For Format: enter a 12h or 24h time to convert it to the other format.
- How do I convert a time from New York to London?
- Open the Timezone Converter tab, enter the time in New York, select "America/New_York" as the source timezone, and "Europe/London" as the target. The converted time appears instantly, automatically accounting for the current UTC offset difference and any daylight saving time in effect.
- How do I calculate how many hours are between two times?
- Use the Duration tab. Enter the start time and end time — the tool calculates the total duration in hours and minutes. If the end time is earlier than the start time, the tool assumes the period crosses midnight and calculates accordingly (e.g. 22:00 to 06:00 = 8 hours).
- What is the difference between 12-hour and 24-hour time format?
- 12-hour format uses AM and PM to distinguish morning and afternoon (12:00 AM is midnight, 12:00 PM is noon). 24-hour format (also called military time) runs from 00:00 to 23:59 with no AM/PM ambiguity — 14:30 is always 2:30 in the afternoon. The Format tab converts between the two in one click.
More in Date & Time
See all date & time.