Date to Unix Timestamp Converter — Epoch Time Made Simple
A Unix timestamp is the universal language of time in software — a single integer that unambiguously represents any moment in history without timezone confusion. This converter takes any human-readable date and time and gives you back the exact epoch value, in either seconds (10-digit) or milliseconds (13-digit), ready to paste into your code, API call, or database.
For milliseconds (13-digit): Timestamp_ms = Timestamp_s × 1000. JavaScript's Date.now() returns ms; use Math.floor(Date.now() / 1000) for seconds.
Seconds vs Milliseconds — the 10-digit vs 13-digit Distinction
The most common source of timestamp bugs is mixing up seconds and milliseconds. A 10-digit timestamp (e.g., 1705312200) counts elapsed seconds and is the native unit for Unix/Linux, Python's time.time(), C's time(), and most REST APIs. A 13-digit timestamp (e.g., 1705312200000) counts elapsed milliseconds — JavaScript's default via Date.now(), and used in Java, Node.js, and browser APIs. If you pass a seconds-based timestamp to JavaScript's new Date() without multiplying by 1000, you will get a date in January 1970.
Timezones and UTC — Why Your Input Timezone Matters
When you type '2024-01-15 10:30 AM', that time is ambiguous without a timezone. 10:30 AM in New York and 10:30 AM in Tokyo are different absolute moments — they correspond to different Unix timestamps. This tool reads your browser's local timezone and converts accordingly. To get a UTC-based timestamp, enter your date in UTC time or account for your offset. Always store timestamps in UTC and convert to local time only for display.
Common Uses of Unix Timestamps in APIs and Databases
JWT tokens use iat (issued at) and exp (expiry) as Unix timestamps in seconds. OAuth 2.0 access tokens express expiry as seconds from epoch. POSIX file metadata (mtime, atime, ctime) is stored as Unix timestamps at the OS level. PostgreSQL and MySQL store TIMESTAMP columns internally as seconds from epoch. Event logs in distributed systems use epoch time to avoid timezone ambiguity across servers in different regions.
The Year 2038 Problem — When 32-bit Integers Run Out
On January 19, 2038 at 03:14:07 UTC, 32-bit signed integer timestamps will overflow to a large negative number — resetting affected clocks to December 1901. This 'Y2K38' problem already affects embedded firmware, older 32-bit Linux kernels, and MySQL TIMESTAMP columns (which have a hard cap at 2038). The fix is migrating to 64-bit integers or DATETIME(6) types, which handle times far beyond any practical concern.
Quick Reference
- API authentication: JWT iat/exp fields, OAuth token_expires_in
- Database sorting and time-range queries (ORDER BY created_at)
- Session expiry and rate limiting windows
- Log timestamps in distributed systems (avoids timezone ambiguity)
- Cache TTL and HTTP Cache-Control: max-age headers
- Scheduled job triggers in cron and message queue systems
- File modification time tracking (mtime, ctime at the OS level)
Frequently Asked Questions
What is a Unix timestamp?
A Unix timestamp is the total number of seconds elapsed since January 1, 1970 at 00:00:00 UTC — known as the Unix Epoch. It is timezone-independent: the same timestamp refers to the same absolute moment in time everywhere in the world, regardless of local timezone.
Why does Unix time start on January 1, 1970?
The date was chosen by the early Unix developers at Bell Labs as a convenient round number close to when Unix was being created (late 1960s–early 1970s). It has no deeper significance — it is simply the agreed-upon reference point for the entire Unix time standard, adopted and maintained ever since.
What is the Year 2038 problem?
Systems that store Unix time as a signed 32-bit integer can represent a maximum value of 2,147,483,647, corresponding to January 19, 2038 at 03:14:07 UTC. After that moment the integer overflows to a large negative number, causing affected clocks to roll back to December 1901. Modern systems use 64-bit integers, which will not overflow for approximately 292 billion years.
Is a Unix timestamp always in UTC?
Yes. A Unix timestamp is always a count of seconds from the UTC epoch — it has no concept of local timezone internally. Your local time offset is applied only when you display the timestamp as a human-readable date string. This is what makes timestamps safe to store and compare across systems in different locations.
What is the difference between a 10-digit and 13-digit timestamp?
A 10-digit timestamp (e.g., 1705312200) counts elapsed seconds — the native unit for Unix/Linux, Python's time.time(), C's time(), and most REST APIs. A 13-digit timestamp (e.g., 1705312200000) counts elapsed milliseconds — JavaScript's default via Date.now(), and used in Java and Node.js. To convert seconds to milliseconds, multiply by 1000.
How do I convert a date to a Unix timestamp in JavaScript?
Use new Date('2024-01-15T10:30:00').getTime() to get milliseconds, then divide by 1000 and floor for seconds: Math.floor(new Date('2024-01-15T10:30:00').getTime() / 1000). For the current moment: Math.floor(Date.now() / 1000).
What timezone should I use when storing timestamps?
Always store timestamps in UTC or as plain Unix timestamps, never in local time. Apply the user's timezone offset only at the display layer. Storing local times in databases causes subtle bugs when servers are in different timezones, when users travel, or when Daylight Saving Time shifts occur.