Timestamp — Free Online Tool on Toolpile
Every tool you need, one place
PDF, Image, AI, Dev, and Business tools — free, private, no signup.
Toolpile uses cookies for analytics and ads. The tools themselves keep your files in the browser — that doesn't change. Read the full policy
PDF, Image, AI, Dev, and Business tools — free, private, no signup.
About Timestamp
A Unix timestamp is the number of seconds since 1 January 1970 UTC — a single integer that uniquely identifies any moment in time, independent of timezones, calendars, or daylight savings. Every database stores them, every log file emits them, every distributed system orders events by them. Converting between timestamp and human-readable date is a trivial operation that breaks in interesting ways. Here's the model and the gotchas.
Before Unix time, computers stored dates as collections of fields — year, month, day, hour, minute, second, sometimes timezone. Every operation ("is this date before that one", "how many days between") needed to handle leap years, leap seconds, varying month lengths, and DST transitions. The 1970 Bell Labs team picked a simpler design: pick an epoch (a fixed reference point) and count seconds from it. Every moment becomes a single integer; arithmetic is just integer math.
1 January 1970 00:00:00 UTC was chosen because it was recent enough to fit Unix's then-32-bit signed integer space without negative values for normal use, and because it was a clean Gregorian date. Negative timestamps work for historical dates (1969 and earlier) but most systems disallow them; positive timestamps cover 1970 to 2038 in 32-bit signed, 1970 to year ~292 billion in 64-bit signed (every modern system).
The unit is seconds in classic Unix tools (`date +%s`), milliseconds in JavaScript (`Date.now()`), and nanoseconds in some monitoring/log systems (Prometheus, Go's `time.Now().UnixNano()`). The most common debugging confusion: comparing a JavaScript `Date.now()` value to a server-emitted Unix timestamp and being off by a factor of 1,000. This tool detects and converts between seconds, milliseconds, and microseconds automatically based on magnitude.
A Unix timestamp doesn't have a timezone. It IS a timezone-independent moment — the same number is "3pm UTC" or "10am New York" or "midnight Tokyo" depending on whose clock you read it on. Confusion happens when developers convert a timestamp to a human-readable date and forget to specify which timezone to display in. JavaScript's `new Date(1700000000000).toString()` shows the date in the user's local timezone — your dev machine and the production server may show different strings for the same timestamp.
Best practice for storage: always store and transmit Unix timestamps (or ISO 8601 with explicit `Z` suffix for UTC). For display: convert to local time at render time, with explicit timezone label ("3:00 PM EST" not "3:00 PM"). The bug pattern is converting on the server (which uses UTC) and serving a string to a browser (which assumes local) — users see times that look 5 hours off.
This tool converts in your browser's local timezone by default and offers explicit UTC, named timezone (`Europe/Amsterdam`, `America/New_York`), and offset-based (`-05:00`) modes. For application code, using a library like `date-fns` or `Luxon` with explicit timezone awareness avoids most surprises.
32-bit signed integers max out at 2,147,483,647 — corresponding to 03:14:07 UTC on 19 January 2038. After that, 32-bit Unix timestamp arithmetic overflows back to 1901. The "Year 2038 problem" is the Y2K of timestamps. Most modern systems moved to 64-bit timestamps in the 2010s; legacy embedded systems, some database schemas, and very old C code still use 32-bit `time_t`. Cars, payment terminals, and SCADA systems are the highest-risk categories — they often run for decades on the original firmware. Audit before 2038.
**Leap seconds**: Earth's rotation isn't perfectly stable, so the International Earth Rotation Service (IERS) inserts a leap second roughly every 18 months to keep UTC aligned with astronomical time. Unix time is supposed to ignore leap seconds — the timestamp on a leap second is the same as the previous one (the system "holds" the count for one second). In practice, different OSes handle this differently and leap seconds have caused outages (Cloudflare 2017, Reddit 2012, multiple Linux freezes 2012). The decision to abolish leap seconds entirely by 2035 was made in 2022; running into them in legacy systems is the practical concern.
**Sub-second precision**: JavaScript stores timestamps in milliseconds. PostgreSQL `timestamptz` stores microseconds. High-frequency trading systems and distributed log systems use nanoseconds. Mixing precisions — comparing a millisecond timestamp to a microsecond one — produces silent bugs (the smaller-precision value looks 1,000× too small). When in doubt, multiply or divide by powers of 1,000 to align precisions before comparing.
**Negative timestamps**: 1 January 1970 00:00:00 UTC = 0. Anything earlier is negative. Most systems handle them; some date pickers and validation libraries reject them. If your application could deal with historical data (genealogy, archives, geology), test negative timestamps explicitly.
Why is my Unix timestamp showing as a date in 1970?
Almost always a units mismatch. JavaScript `Date.now()` returns milliseconds; many other languages and tools return seconds. Pasting `1700000000` (seconds) into a milliseconds-expecting parser gives you a date in 1970 because 1.7 billion milliseconds is only ~20 days from epoch. Multiply by 1000 to convert seconds → ms, divide by 1000 for ms → seconds.
Why does the same timestamp show different dates on different machines?
The timestamp is the same; the displayed timezone differs. A timestamp converted on a US East machine displays as EST/EDT; the same timestamp on a UTC server displays 4-5 hours later. To get consistent display across machines, always specify the target timezone explicitly — this tool defaults to your local browser timezone but offers UTC and named alternatives.
What's the difference between Unix time and ISO 8601?
Unix time is an integer (`1700000000`); ISO 8601 is a string (`2023-11-14T22:13:20Z`). Both unambiguously identify a moment. Unix time is more compact in databases and APIs; ISO 8601 is more readable. Most modern APIs use ISO 8601 in JSON because the strings are self-describing; databases store Unix integers because they're 4-8 bytes vs 24-byte strings.
How do I add 30 days to a Unix timestamp?
30 × 24 × 60 × 60 = 2,592,000 seconds. Add that to your Unix timestamp. In code, use a date library (`date-fns: addDays(date, 30)`) instead of raw arithmetic — it handles edge cases like daylight savings (which can make a "day" 23 or 25 hours instead of 24) and leap seconds. Raw seconds-arithmetic is fine for fixed durations but breaks subtly when the duration spans a DST boundary.
Will the 2038 problem affect me?
If your stack is modern (any 64-bit OS, any language released post-2010, any cloud database), no — 64-bit timestamps work until year 292 billion. The risk is legacy systems: 32-bit embedded firmware, older database schemas with 4-byte `int` columns for timestamps, custom C code with `time_t` not explicitly typed as 64-bit. Audit those before 2038. Most production code in 2026 is already 64-bit-safe.