A moment in time is one value wearing many costumes: "3 PM in New York", "19:00 UTC", "1,000,000,000 seconds since 1970", "09/09/2001" — which, in half the world, reads as the 9th of September and in the other half looks suspiciously like it might not. Time conversion is the most gotcha-dense corner of everyday conversions because clocks carry politics (timezones, daylight saving) on top of arithmetic. This guide explains the three systems that make times convertible — UTC offsets, the Unix epoch, and calendar date math — with worked examples you can verify, and flags the traps that produce meetings joined an hour late. When you just need the answer, a free in-browser converter applies all these rules instantly.
UTC: the reference everything converts through
Every timezone is defined as an offset from UTC (Coordinated Universal Time). New York in summer is UTC−4; Berlin in summer is UTC+2; India is UTC+5:30 year-round. Converting between two zones is always the same two steps:
- Local time → UTC (subtract the offset — or add, if it's negative).
- UTC → target local time (add the target's offset).
Worked example — 3:00 PM in New York (summer) to Berlin time:
- New York summer time (EDT) is UTC−4, so 15:00 − (−4) = 19:00 UTC.
- Berlin summer time (CEST) is UTC+2, so 19:00 + 2 = 21:00 — 9 PM.
Six hours apart. In winter the offsets both shift (EST is UTC−5, CET is UTC+1) and the gap is still six hours — which tempts people to memorise "NY to Berlin = +6" as a constant. That shortcut fails in the gotcha below.
Gotcha 1: the DST mismatch window
Regions don't switch to daylight saving on the same date. The United States springs forward on the second Sunday of March; the European Union on the last Sunday of March. For those two-to-three weeks, New York is on UTC−4 while Berlin is still on UTC+1 — a five-hour gap instead of six. The same mismatch happens (reversed) around the autumn switch, and the southern hemisphere flips in the opposite months entirely. Moral: convert via UTC using each zone's offset on that date — never via a memorised difference.
Gotcha 2: offsets aren't all whole hours
India is UTC+5:30, Nepal UTC+5:45, and parts of Australia use UTC+9:30. Any mental model that only shifts whole hours will be wrong by fractions in a large slice of the world.
Gotcha 3: abbreviations lie
"CST" is Central Standard Time (UTC−6), China Standard Time (UTC+8), and Cuba Standard Time (UTC−5). When precision matters, use a city ("time in Chicago") or an explicit offset ("14:00 UTC−6"), not a three-letter code.
Unix timestamps: time as one big number
Computers sidestep all of the above by storing a moment as a single count: the Unix timestamp — seconds elapsed since 1970-01-01 00:00:00 UTC (the "epoch"). No zones, no DST, no formats: 1,000,000,000 is the same instant everywhere on Earth; only its display as local time differs.
You can decode one by hand. Take t = 1,000,000,000:
- Days: 1,000,000,000 ÷ 86,400 (seconds per day) = 11,574 days, remainder 6,400 s.
- Count 11,574 days forward from 1970-01-01. The years 1970–2000 contain 31 years with 8 leap years (1972, '76, '80, '84, '88, '92, '96, 2000), so 2001-01-01 is day 31 × 365 + 8 = 11,323. That leaves 11,574 − 11,323 = 251 days into 2001.
- Walking the months (Jan 31, Feb 28, … Aug 31 = day 243) lands day 251 on September 9.
- The remainder 6,400 s = 1 h 46 min 40 s.
Result: 2001-09-09 01:46:40 UTC — the "billennium", celebrated by exactly the kind of people who read this far. The same method puts t = 2,000,000,000 at 2033-05-18 03:33:20 UTC. (Every step above is integer arithmetic you can re-check; a converter just does it in microseconds.)
Timestamp gotchas, in the order they'll bite you:
- Seconds vs milliseconds. JavaScript's
Date.now()returns milliseconds; most APIs and Unix tools use seconds. A 10-digit number is seconds; 13 digits is milliseconds. Feed milliseconds where seconds are expected and your date lands tens of thousands of years out — feed seconds as milliseconds and everything happens in January 1970. - Timestamps are UTC, full stop. "Convert 1,000,000,000 to my timezone" means: decode to UTC, then apply your offset. There is no such thing as a timestamp "in Eastern time".
- Negative timestamps are valid — they're moments before 1970.
- The year 2038 problem: systems storing the count in a signed 32-bit integer overflow at 2,147,483,647 — 2038-01-19 03:14:07 UTC. Modern 64-bit systems are fine for a few hundred billion years.
Date math: where calendars fight back
Durations between dates look like subtraction but ride on an irregular calendar. The reliable method is day-of-year arithmetic:
How many days from January 1 to July 4 (same non-leap year)? July 4 is day 31 + 28 + 31 + 30 + 31 + 30 + 4 = 185 of the year, and January 1 is day 1, so the difference is 185 − 1 = 184 days. (People often expect "about half a year = 182.5" — close, but paying interest on the wrong number adds up.)
The leap-year rule that feeds this math: a year is a leap year if it's divisible by 4, except century years, which must be divisible by 400. So 2024 was a leap year, 2026 is not, 2000 was, and 1900 was not — the exception that broke more than one old spreadsheet.
Two duration gotchas:
- "A month" is not a unit. January 31 plus one month is February 28 (or 29) in most software — the day gets clamped. Two "one-month" steps from January 31 land on March 28, not March 31. If a contract or subscription says months, the rule for month-ends matters as much as the count.
- Inclusive vs exclusive counting. Monday to Friday is 4 days elapsed but 5 days listed. Off-by-one errors in deadlines are almost always this.
Age calculation is the same math with a birthday twist: someone born 1998-03-15 is 27 on 2026-03-14 and turns 28 on 2026-03-15 — an age calculator just counts whole completed years, clamping February 29 birthdays to February 28 or March 1 depending on the jurisdiction's rule (another convention, not a computation).
Writing dates so they convert cleanly
The final trap is notation. "04/07/2026" is April 7 in the US and 4 July
nearly everywhere else — the reason machine-facing dates should always be
ISO 8601: 2026-07-06, biggest unit first, zero-padded. It's
unambiguous, it sorts correctly as plain text, and with a time and offset
attached (2026-07-06T15:00:00-04:00) it pins a single instant with no
guesswork. In prose, spell the month out ("6 July 2026") and no reader can
mis-parse it.
That "one value, many notations" pattern isn't unique to time — it's the same story as metric vs imperial units and hex vs RGB vs HSL colour codes: pick the unambiguous form for machines, the friendly form for humans, and convert deliberately between them.
FAQ
What exactly is a Unix timestamp?
The number of seconds elapsed since 1970-01-01 00:00:00 UTC, ignoring leap seconds. It identifies one instant globally — 1,000,000,000 corresponds to 2001-09-09 01:46:40 UTC — and only its display as local time varies by timezone.
How do I tell if a timestamp is in seconds or milliseconds?
By length, for contemporary dates: 10 digits is seconds, 13 digits is milliseconds. If a decoded date lands around 1970 you probably divided milliseconds as if they were seconds already-small; if it lands tens of thousands of years ahead, you fed milliseconds to a seconds field.
Why did my timezone conversion come out an hour off?
Almost always daylight saving: either the zone's offset changed on that date, or the two regions switch to DST on different dates (the US changes in early March, the EU in late March), temporarily shrinking or stretching their usual gap. Convert via UTC using each zone's offset for the specific date.
What's the safest date format to use?
ISO 8601 — 2026-07-06, extended with time and offset as
2026-07-06T15:00:00-04:00 when the instant matters. It can't be misread as
DD/MM vs MM/DD and sorts chronologically as text. In sentences, write the
month as a word.
Need a timestamp decoded or a meeting time moved across zones right now? Medley Web is building a free hub of instant, in-browser tools — timezone conversion, epoch timestamps, duration and age calculators among them — one input in, many formats out. Convert times and dates free at medley-web.com.
