Skip to content
yutils
Example

Input

1715600000

Output (both directions)

Unix (seconds):      1715600000
Unix (milliseconds): 1715600000000
ISO 8601:            2024-05-13T13:33:20.000Z
UTC:                 Mon, 13 May 2024 13:33:20 GMT
Local:               2024-05-13 22:33:20 (KST)

Note

10-digit input is seconds, 13-digit is milliseconds (auto-detected). Date strings in ISO 8601, RFC 2822, or freeform formats are also accepted.

Usage / FAQ

When to use

  • Make Unix timestamps in API responses (JWT exp, MongoDB ObjectId, …) human-readable
  • Convert DB log epoch times to your local timezone
  • Generate the current timestamp with one click (now button)
  • Round-trip ISO 8601 ↔ epoch while debugging
  • Represent absolute time independent of timezone

FAQ

Q.How are seconds vs milliseconds distinguished?
A.By digit count — 10 digits = seconds, 13 = milliseconds. JavaScript Date uses ms; Unix / Python's `time.time()` uses seconds. The most common 1000× bug.
Q.What is Y2K38?
A.The 32-bit signed int rolls over on Jan 19, 2038 at 03:14:07 UTC. Modern 64-bit timestamps are safe for ~290 billion years.
Q.What if the timestamp is negative?
A.It's a moment before 1970-01-01. E.g. -86400 is 1969-12-31. Some legacy systems can't handle negative epoch times — be careful.
Fun facts
  • 1970-01-01 00:00:00 UTC is the Unix epoch — set by Bell Labs while building PDP-11 Unix. Curiously, the *first* Unix Programmer's Manual (Nov 1971) used a 1971-01-01 epoch before settling on 1970.

    Wikipedia — Unix time
  • At 2038-01-19 03:14:07 UTC, signed 32-bit Unix time overflows. Dubbed the 'Year 2038 problem' — Y2K's successor — and very real for embedded systems and `int32` DB columns. 64-bit time has another ~290 billion years of headroom.

    Y2038 problem
  • Unix time ignores leap seconds. UTC and Unix time diverge by the accumulated leap-second count (27 seconds as of 2025), and at a leap-second event Unix time effectively repeats the same second rather than expressing `23:59:60`.

    Wikipedia — Leap second