Every date you see on a screen — "March 31, 2026" or "04/18/2026 3:45 PM" — is a human convenience. Under the hood, most systems store time as a single number. That number is a Unix timestamp, and once you understand it, a surprising amount of debugging and API work gets easier.
What is a Unix timestamp?
A Unix timestamp (also called epoch time or POSIX time) is the number of seconds that have passed since January 1, 1970, at 00:00:00 UTC. That specific moment is called the Unix epoch.
Right now, as you read this, the timestamp is somewhere around 1,775,000,000. That's roughly 1.7 billion seconds since 1970. Every second, the number ticks up by one. No time zones, no daylight saving quirks, no date formatting arguments. Just a steadily increasing integer.
Why 1970? It was a practical choice by the engineers who built Unix at Bell Labs. The system needed a starting point, and January 1, 1970 was recent enough to be useful without wasting bits on dates nobody would need.
Why developers and APIs use epoch time
If timestamps are just big numbers, why does anyone prefer them over normal dates? A few reasons.
Time zone neutrality. A Unix timestamp means the same instant everywhere on Earth. When your server in Virginia talks to a database in Frankfurt and a frontend in Tokyo, there's zero ambiguity. The number 1713427200 is the same moment regardless of who reads it.
Easy math. Want to know how many seconds between two events? Subtract one timestamp from the other. Need to add 24 hours? Add 86,400. Date arithmetic with formatted strings is a headache — with timestamps, it's basic subtraction.
Sorting and comparison. Databases can sort integers faster than parsing date strings. An index on a timestamp column is just a number comparison. That matters when you're querying millions of rows.
Compact storage. A 10-digit integer takes less space than "2026-04-18T14:30:00.000Z". At scale, that adds up.
You'll find Unix timestamps everywhere: API responses from Stripe, Twilio, and Slack. JWT tokens. Database created_at columns. Git commit metadata. Log files. If you work with any of these, you're already dealing with epoch time whether you realize it or not.
How to read a Unix timestamp
The number 1713427200 doesn't tell you much at first glance. So how do you turn it into a date?
The quickest way is to paste it into a Unix to Date converter. You'll see the human-readable date, the time in your local zone, and the UTC equivalent — all instantly.
If you want to do it manually, here's the logic. Divide the timestamp by 86,400 (the number of seconds in a day) to get the number of days since January 1, 1970. Then count forward through years, accounting for leap years, until you land on the right date. In practice, nobody does this by hand — that's what libraries and tools are for.
In JavaScript
const timestamp = 1713427200;
const date = new Date(timestamp * 1000); // JS uses milliseconds
console.log(date.toISOString());
// "2024-04-18T08:00:00.000Z"
Note the * 1000. JavaScript's Date object expects milliseconds, not seconds. This trips up developers constantly.
In Python
from datetime import datetime
timestamp = 1713427200
dt = datetime.utcfromtimestamp(timestamp)
print(dt) # 2024-04-18 08:00:00
In PHP
echo date('Y-m-d H:i:s', 1713427200);
// 2024-04-18 08:00:00
How to convert a date to a Unix timestamp
Going the other direction — from a human date to a number — is just as common. You might need to set an expiration time in an API request, schedule a future event, or store a date in a database column that expects an integer.
Use the Date to Unix converter to pick a date and time visually and get the timestamp back. No mental math required.
In code, the approach varies by language:
// JavaScript
const ts = Math.floor(new Date('2026-04-18T12:00:00Z').getTime() / 1000);
# Python
import calendar, time
ts = calendar.timegm(time.strptime('2026-04-18 12:00:00', '%Y-%m-%d %H:%M:%S'))
The key gotcha here is time zones. If you create a date object without specifying UTC, most languages assume local time. That means the same code produces different timestamps on different machines. Always be explicit about UTC when converting dates to timestamps.
Milliseconds vs. seconds
Not all timestamps use seconds. JavaScript timestamps are in milliseconds (13 digits instead of 10). Some APIs return microseconds. Others return seconds as a floating-point number with decimal places.
How do you tell which format you're looking at?
- 10 digits (like
1713427200) — seconds since epoch - 13 digits (like
1713427200000) — milliseconds since epoch - 16 digits — microseconds (rarer, but used in some logging systems)
When you're debugging an API response and the dates look wrong by a factor of 1,000, you've probably mixed up seconds and milliseconds. It happens to everyone.
The Year 2038 problem
Here's something worth knowing. Many older systems store Unix timestamps as a 32-bit signed integer. The maximum value a 32-bit signed integer can hold is 2,147,483,647 — which corresponds to January 19, 2038, at 03:14:07 UTC.
After that moment, the counter overflows. It wraps around to a negative number, which the system interprets as December 13, 1901. Sound familiar? It's the same class of bug as Y2K, just with a different calendar deadline.
Modern 64-bit systems don't have this issue — a 64-bit timestamp won't overflow for about 292 billion years. But embedded systems, legacy databases, and some IoT devices still use 32-bit timestamps. If you maintain older systems, 2038 isn't that far away.
Common mistakes when working with timestamps
Assuming local time. The most frequent bug. A timestamp is always UTC. If you display it without converting to the user's time zone, your dates will be wrong for most of your audience.
Forgetting leap seconds. Unix time doesn't count leap seconds. A Unix day is always exactly 86,400 seconds, even though real days occasionally have 86,401. For most applications this doesn't matter, but if you're building something that needs sub-second precision over decades, it's worth understanding.
Storing timestamps as strings. Some developers store "1713427200" as a VARCHAR in their database instead of an integer. This breaks numeric sorting, wastes storage, and makes queries slower. Use an integer column or your database's native timestamp type.
Negative timestamps. Dates before January 1, 1970 have negative Unix timestamps. December 31, 1969 23:59:59 UTC is -1. Most languages handle this fine, but some validation logic incorrectly rejects negative timestamps as invalid.
Quick reference
| Date | Unix Timestamp | |------|---------------| | Jan 1, 1970 00:00 UTC | 0 | | Jan 1, 2000 00:00 UTC | 946684800 | | Jan 1, 2025 00:00 UTC | 1735689600 | | Jan 19, 2038 03:14:07 UTC | 2147483647 (32-bit max) |
Tools that make this easier
You don't need to memorize conversion formulas or keep a terminal open just to decode a timestamp from a log file. The Unix to Date converter handles timestamp-to-date conversion instantly, and the Date to Unix converter goes the other direction. Both run entirely in your browser — nothing gets sent to a server.
Paste a timestamp, get a date. Pick a date, get a timestamp. That's it. Keep them bookmarked and you'll save yourself a surprising number of Stack Overflow trips.