Unix Timestamp Converter
Direction
Auto-detects milliseconds (13-digit input).
Share with friends
How to use
- 1 Click Now to insert the current Unix timestamp, or paste your own value.
- 2 Choose timezone (default UTC). Common picks: America/New_York, America/Los_Angeles, Europe/London, Asia/Tokyo.
- 3 For epoch → date: paste seconds (10 digits) or milliseconds (13 digits) — the converter auto-detects.
- 4 For date → epoch: enter ISO 8601 datetime (YYYY-MM-DDTHH:MM) and pick timezone.
- 5 Output shows local datetime in chosen timezone, ISO 8601, GMT/UTC, and the day of week.
About Unix Timestamp Converter
FAQ
Q Why is my Unix timestamp 13 digits instead of 10?
Yours is in milliseconds, not seconds. Seconds-based timestamps are 10 digits through year 2286; milliseconds-based are 13 digits. JavaScript's <code>Date.now()</code>, Java <code>System.currentTimeMillis()</code>, and Kafka all use milliseconds; Unix command line and most databases use seconds. The converter auto-detects.
Q How do I convert epoch time to my local timezone?
A Unix timestamp is timezone-independent — it represents an instant in UTC. To display it in local time, pick your IANA timezone (America/New_York, etc.). The same epoch value renders as different wall-clock times depending on the timezone you choose, but it's the same instant.
Q What happens to Unix timestamps after January 19, 2038?
On 32-bit signed systems, timestamps overflow at 03:14:07 UTC on Jan 19, 2038, wrapping to December 13, 1901. Modern 64-bit systems are unaffected. Audit any embedded systems, legacy databases, or 32-bit applications still in production for the Year 2038 problem before then.
Q Is Unix time the same as UTC?
Mostly — Unix time counts SI seconds since 1970-01-01 UTC, but it ignores leap seconds. UTC has had 27 leap seconds added since 1972, so Unix time and true UTC differ by that amount. Most applications don't care; high-precision timing (GPS, financial trading, astronomy) does.
Q How do I get the current Unix timestamp in JavaScript / Python / Bash?
JavaScript: <code>Math.floor(Date.now() / 1000)</code>. Python: <code>int(time.time())</code>. Bash: <code>date +%s</code>. PHP: <code>time()</code>. Go: <code>time.Now().Unix()</code>. All return seconds since the epoch.
Q Why do my Unix timestamps differ by hours between systems?
Most likely a timezone or DST mismatch. A timestamp itself is timezone-neutral, but if any layer in your pipeline parses a wall-clock string without specifying timezone, it assumes the local one. Always serialize with explicit timezone (ISO 8601 with Z or offset) when sending across systems.
Q What is the difference between ISO 8601 and RFC 3339?
RFC 3339 is a stricter Internet profile of ISO 8601. ISO 8601 allows variations like dropped colons (20260507T143000) or week-based dates (2026-W19-3); RFC 3339 mandates the unambiguous full form (2026-05-07T14:30:00Z). HTTP, JSON APIs, and email use RFC 3339; the broader ISO 8601 is more flexible but harder to parse reliably.
Q Should I store dates as strings or Unix timestamps?
Depends on use. Unix timestamps are compact, sortable, and timezone-neutral — ideal for event timing and logs. ISO 8601 strings are human-readable and self-documenting — better for user-facing data and APIs that may be read by humans. Many systems store both: timestamp internally, ISO 8601 in API responses.
Official resources
IETF RFC 3339 — Date and Time on the Internet
Authoritative IETF specification for date/time format used in HTTP, JSON, and most Internet protocols.
IANA Time Zone Database
Official IANA tz database — the source of truth for timezone names and DST rules used worldwide.
Wikipedia — Year 2038 Problem
Background on the 32-bit Unix time overflow and remediation strategies.
POSIX.1-2017 — Unix Time Definition
Authoritative POSIX specification of Unix time (Seconds Since the Epoch).