What Is a Unix Timestamp? Understanding 1700000000 (With a Converter)
Seen a number like 1700000000 in a database, API or log and wondered what it means? This plain-English guide explains the Unix timestamp, why programs use it, seconds vs milliseconds, time zones, and how to convert to and from dates online.
When you're coding, or reading a database or log, you'll bump into numbers like 1700000000 — clearly a time, but completely unreadable. That's a Unix timestamp, the most universal way programs record time. Understand it and time-related data stops being confusing.
What is a Unix timestamp?
A Unix timestamp is: the number of seconds elapsed since 1 January 1970, 00:00:00 (UTC), up to some moment.
1700000000 → ~15 November 2023 (UTC)
0 → 1 January 1970, 00:00:00 (the starting point)
One number precisely represents one moment. That 1970 starting point is often called the "Unix epoch."
Why do programs use it?
Because numbers are the easiest thing to work with:
- Easy intervals: subtract two timestamps to get the seconds between them.
- Easy sorting: just compare values, no date parsing.
- No format or time-zone ambiguity: dates have many formats and zones; a timestamp is one UTC-based number.
So the convention is: use timestamps for internal logic, convert to a readable local date only for display.
Seconds vs milliseconds: check the digits
The most common gotcha — the unit:
| Digits | Unit | Example |
|---|---|---|
| 10 | seconds | 1700000000 |
| 13 | milliseconds | 1700000000000 |
Milliseconds is just seconds × 1000. JavaScript defaults to milliseconds while many back ends use seconds, so mixing them causes 1000x errors. The digit count tells you the unit.
Watch the time zone
Timestamps are UTC-based. If you're in UTC+8, your local time is 8 hours ahead of UTC for the same timestamp. If a converted time is off by exactly your zone offset, that's a time-zone handling issue — not a wrong timestamp.
How to convert to and from dates
The fastest way is our Unix timestamp converter — it shows the live current timestamp (copy in one click), converts a pasted timestamp into a date (auto-detecting seconds vs milliseconds), or turns a chosen date back into a timestamp, showing both local and UTC time for reference.
1700000000 → 2023-11-15 06:13:20 (UTC)
The bottom line
A Unix timestamp is "the number of seconds since 1970" — one number for one moment — which programs love because it's easy to compute, sort, and free of time-zone ambiguity. Remember two things: 10 digits is seconds, 13 is milliseconds; and it's UTC-based, so add your offset (e.g. +8) for local time. To convert, drop it into the Unix timestamp converter. For other common developer formats, see what JSON is and what Base64 is.
FAQ
What is a Unix timestamp?
A Unix timestamp is the number of seconds elapsed since 1 January 1970, 00:00:00 UTC — a single number representing a moment in time. For example, 1700000000 is a moment in mid-November 2023. Because it's a plain number with no time-zone or formatting ambiguity, programs, databases and APIs almost always use it internally, converting to a readable date only when showing it to people.
Why do programs use timestamps instead of dates?
Because a number is the simplest thing to work with. Dates come in many formats (2026/06/17, June 17…) and time zones, which makes comparing, calculating and sorting messy. A timestamp is one number: subtract two to get the gap in seconds, sort by comparing values, and there's no time-zone ambiguity (it's UTC-based). So internal logic uses timestamps and converts to a local date only for display.
What's the difference between a 10-digit and a 13-digit timestamp?
The digit count signals the unit. 10 digits (like 1700000000) is usually seconds; 13 digits (like 1700000000000) is milliseconds — three extra digits is seconds times 1000. Many languages (like JavaScript) default to milliseconds while other systems use seconds, so mixing them causes 1000x errors. Check the digit count to tell the unit.
Why does the displayed time differ from mine by a few hours?
Time zones. The timestamp itself is UTC-based, so a converter shows your local time by applying your zone — if you're in UTC+8, your local time is 8 hours ahead of UTC. If your converted time is off by exactly your zone offset, that's a time-zone handling issue, not a wrong timestamp.