Convert a Date to a Unix Timestamp

A Unix timestamp is an instant since 1970-01-01T00:00:00Z. Going from a human date to that integer is the inverse of formatting an epoch as a string: you must know whether the clock you typed was UTC or local, and whether the API wants seconds or milliseconds.

The two decisions that matter

Decision	Why it bites
UTC vs local input	Same “15:00” is a different instant in IST vs UTC
Seconds vs ms output	10-digit vs 13-digit values break APIs

The integer itself has no timezone inside it. Timezone only affects how you interpret the calendar fields you entered.

Practical workflow

1. Write the date/time you mean (include offset or say “UTC” / “local”).
2. Convert to an absolute instant.
3. Emit seconds (Math.floor(ms / 1000)) or milliseconds (Date.getTime() style) to match the consumer.
4. Round-trip: convert the integer back and confirm the same wall clock in the intended zone.

Example mindset: “2026-07-16 09:00 in Asia/Kolkata” is not the same epoch as “2026-07-16 09:00 UTC.”

Common mistakes

• Treating a local wall time as UTC (off by your offset, e.g. 5:30 in IST).
• Sending milliseconds to an API that documents Unix seconds.
• Parsing YYYY-MM-DD as UTC in one language and local midnight in another.
• Forgetting that epoch is timezone-agnostic — only display strings carry zones.

The ambiguity you have to resolve first

A date string on its own is not enough information to produce a timestamp. 2026-01-15 09:00 could be nine in the morning in any timezone on earth, and each one yields a different epoch. Before converting, you have to decide which of these you meant:

Input form	Interpreted as	Notes
2026-01-15T09:00:00Z	UTC	Unambiguous — the Z fixes it
2026-01-15T09:00:00+05:30	That explicit offset	Unambiguous
2026-01-15T09:00:00	Depends on the parser	This is where bugs come from
2026-01-15	Midnight, zone-dependent	Date-only is the worst offender

That third row is the trap: an offset-less string is treated as UTC by some parsers and as local time by others, so identical code produces different timestamps on a developer laptop and a UTC production server. Always carry an explicit offset, or state the assumed zone in one place.

Date-only values and the off-by-one day

2026-01-15 with no time attached becomes midnight — and midnight is exactly where a timezone shift changes the calendar date. Convert midnight local to UTC in a zone behind UTC and you land on the 14th; convert midnight UTC to a zone ahead and you land on the 16th.

This is the cause of nearly every “birthday shows one day early” and “report is off by a day” bug. When a value is genuinely a calendar date rather than an instant — a birthday, an invoice date, a holiday — the safest handling is to keep it as a plain date string and never route it through timezone conversion at all.

Round-tripping safely

Converting a date to a timestamp and back should return what you started with. It usually will if you follow three rules:

1. Parse with an explicit offset, or explicitly state the zone you are assuming.
2. Store the epoch (or a UTC ISO 8601 string) — never a locale-formatted string like 15/01/2026, whose meaning depends on the reader’s conventions.
3. Format for display only at the last step, using the viewer’s zone.

The rule of thumb: an instant is a number; a calendar date is text. Treating one as the other is what produces almost all date bugs.

Use TryDevSnip Timestamp Converter

TryDevSnip Timestamp Converter converts human dates ↔ Unix epoch in the browser, with a live clock for sanity checks. Not uploaded to our servers for processing.

Also see: seconds vs milliseconds and UTC vs local display.

Privacy one-liner: conversion happens on your device.

FAQ

Does flying change the timestamp for “now”?

No. “Now” is the same instant; only formatted local time changes.

Should APIs store epoch or ISO strings?

Either works if the unit/zone rules are documented. Many systems store UTC ISO or epoch seconds and localize only in the UI.

Why is my converted epoch off by one day?

Often a midnight parse in UTC vs local, or a missing offset on a date-only string.

Fractional seconds?

Some databases store sub-second epochs. Truncate or round explicitly for integer APIs.