ThisCalculator

Everyday

Unix Timestamps: Seconds, Milliseconds & Time Zones

Updated · Standard formula, shown below

Unix Timestamps: Seconds, Milliseconds & Time Zones

Unix timestamps are a universal way to represent a moment in time as a single number. This guide explains how they count seconds (and milliseconds) from an epoch, and why time zones don’t change the timestamp itself—only how you display it. You’ll learn to read, convert, and avoid common pitfalls when working with them in code or tools.

What You’ll Need

  • A basic understanding of what a number represents (no programming required)
  • Access to a command line (Terminal on macOS/Linux, Command Prompt on Windows) or an online converter
  • Optional: a programming environment (Python, JavaScript, etc.) if you want to test conversions

Step-by-Step

  1. Understand the epoch. The Unix epoch is January 1, 1970, 00:00:00 UTC. A Unix timestamp is the number of seconds (or milliseconds) that have elapsed since that exact moment, not counting leap seconds.
  2. Know the units. Most systems use seconds (10 digits, e.g., 1718000000). Some APIs and databases use milliseconds (13 digits, e.g., 1718000000000) for higher precision. Always check which unit your data uses.
  3. Convert seconds to a human-readable date. In a Unix shell, run date -d @1718000000 (Linux) or date -r 1718000000 (macOS). On Windows PowerShell, use [DateTimeOffset]::FromUnixTimeSeconds(1718000000). This gives you the UTC time.
  4. Convert milliseconds to seconds first. If your timestamp is in milliseconds, divide by 1000 before converting. For example, 1718000000000 ms ÷ 1000 = 1718000000 s. Then convert as above.
  5. Understand time zones. The timestamp itself is time-zone agnostic. It represents an absolute point in time. The same timestamp corresponds to different local times in different time zones. For example, 1718000000 is 12:00:00 UTC on June 10, 2024, but 08:00:00 in New York (EDT) and 14:00:00 in Berlin (CEST).
  6. Convert to a specific time zone. When displaying, always convert the UTC time to the desired local time zone. In programming, use libraries like datetime in Python with pytz or zoneinfo, or Intl.DateTimeFormat in JavaScript with a time zone option.
  7. Convert a local time back to a timestamp. Take the local time, apply the correct UTC offset (including daylight saving rules), and then calculate the seconds since epoch. Most languages have functions for this, e.g., Date.UTC() in JavaScript or time.mktime() in Python.
  8. Handle milliseconds in code. In JavaScript, Date.now() returns milliseconds. In Python, use time.time() * 1000 for milliseconds. When comparing timestamps, ensure both are in the same unit.

Common Mistakes

  • Mixing seconds and milliseconds. A 13-digit number is milliseconds; a 10-digit number is seconds. Using the wrong unit can shift the date by decades (e.g., 1718000000 ms is in 1970, not 2024).
  • Assuming a timestamp is in your local time zone. Timestamps are always UTC-based. If you treat a timestamp as local, you’ll get incorrect times.
  • Ignoring daylight saving time. When converting to a local time zone, remember that offsets change. Hardcoding an offset like +5:00 will be wrong half the year.
  • Using date command without the right flag. On Linux, date -d @timestamp works; on macOS, it’s date -r timestamp. Using the wrong one gives an error.

Tips

  • Always store timestamps in UTC and convert only for display. This avoids ambiguity.
  • Use milliseconds for sub-second precision, but be consistent across your application.
  • For debugging, use online converters or command-line tools to quickly check a timestamp.
  • In databases, use the native timestamp type rather than storing as a string to avoid format issues.
  • When programming, use built-in date/time libraries—they handle time zones and leap seconds for you.

Troubleshooting

  • My timestamp gives a date in 1970. This usually means you’re treating milliseconds as seconds. Divide by 1000.
  • The time is off by a few hours. Check if you’re converting to the correct time zone. Also, verify whether daylight saving is in effect for that date.
  • My conversion command fails. Ensure you’re using the correct syntax for your OS. On Windows, use PowerShell instead of CMD.
  • I get a negative timestamp. This represents a date before 1970. Some systems don’t support negative timestamps, so check your data source.
  • My programming language gives a different result. Ensure you’re using the correct method for the unit—some languages default to seconds, others to milliseconds.

Frequently Asked Questions

  1. What is the Unix epoch? It’s January 1, 1970, 00:00:00 UTC. The timestamp counts seconds (or milliseconds) since then.
  2. Do Unix timestamps account for leap seconds? No, they ignore leap seconds. The Unix time system treats each day as exactly 86,400 seconds, so it drifts slightly from atomic time.
  3. Why do some timestamps have 10 digits and others 13? 10 digits are seconds, 13 digits are milliseconds. The extra three digits represent the fractional seconds.
  4. How do I convert a timestamp to my local time? First convert to UTC, then apply your time zone’s offset (including DST). Most programming languages have functions for this.
  5. Can a timestamp be negative? Yes, negative timestamps represent dates before 1970. For example, -86400 is December 31, 1969.
  6. What happens on January 19, 2038? On 32-bit systems, the timestamp will overflow because the maximum value is 2,147,483,647. This is known as the Year 2038 problem. Most modern systems use 64-bit integers, avoiding this issue.

Related

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.