Frequently asked questions about epoch time, timestamps, and conversions.

A Unix timestamp (also called epoch time or POSIX time) is the number of seconds that have elapsed since January 1, 1970 at 00:00:00 UTC. That moment is called the Unix epoch. As of right now, a Unix timestamp is a 10-digit number around 1.78 billion. The system was designed in 1969–1970 at Bell Labs and has become the universal way computers represent time internally.

Two reasons. First, Bell Labs needed a reference point for their new operating system (which became Unix), and January 1, 1970 was a convenient round date that was recent enough that timestamps wouldn't grow unmanageably large in 32-bit integers. Second, 1970 was the year before Unix's first stable release, so anchoring time to it kept the math simple. It was an arbitrary choice that became universal.

You can see the current Unix timestamp at the top of our main converter page — it updates every second in seconds, milliseconds, and microseconds. The value changes every second, so by the time you read this answer, the number you saw on the converter is already a few seconds out of date.

Unix time represents seconds since 1970-01-01 UTC, so the two are tightly related — but they're not the same thing. UTC is a way to express time using calendars (year, month, day, hour, minute, second). Unix time is a single number. You can convert between them, but UTC has timezone offsets and DST rules that Unix time doesn't. Unix time is also strictly increasing (mostly — see leap seconds), while UTC has leap second insertions that make a 61-second minute happen occasionally.

Unix seconds is a 10-digit number (about 1.78 billion right now). Unix milliseconds is a 13-digit number, 1000× larger. JavaScript and most modern web APIs use milliseconds. C, Unix command line, and most databases default to seconds. To convert: seconds × 1000 = milliseconds. Our main converter shows both side by side, and auto-detects which one you've pasted by counting digits.

The easiest way: paste the timestamp into our main converter. It auto-detects whether your value is in seconds, milliseconds, microseconds, or nanoseconds, and shows you ISO 8601, RFC 2822, UTC, your local timezone, and a relative time (e.g., "3 hours ago"). In code, the conversion depends on your language — see our language-specific guides for ready-to-paste examples.

The main converter accepts dates in most common formats — ISO 8601 (2026-05-15T14:30:00Z), RFC 2822, or natural language like tomorrow at 3pm. Paste any of these and it returns the equivalent Unix timestamp. In code, each language has its own approach: JavaScript Date.parse(), Python datetime.timestamp(), Java Instant.parse(), etc.

Yes — the batch converter accepts up to 10,000 timestamps at a time, one per line. It auto-detects the format of each line independently (so you can mix seconds, milliseconds, and ISO 8601 in the same input), and exports the results to CSV or JSON.

Use our duration calculator. Paste a start timestamp and an end timestamp (either as Unix numbers or readable dates) and it returns the duration in seconds, minutes, hours, days, weeks, and a human-readable breakdown. URL sharing is built in, so you can send the link to anyone with both inputs preserved.

Once the page has loaded, yes. All conversion happens in your browser using JavaScript — there's no server call when you paste a value or change the timezone. If you save the page locally with File → Save As, you can use it offline indefinitely.

No. The converter runs entirely in your browser. Nothing you type, paste, or convert is transmitted anywhere. The only way a value leaves your machine is if you explicitly click the "Copy share link" button, which puts the value in the URL — and even then, only you have that URL until you choose to share it. See our privacy policy for the full details.

In casual use, they're the same. Strictly: UTC (Coordinated Universal Time) is the modern standard maintained by atomic clocks worldwide, with leap second insertions to stay aligned with Earth's rotation. GMT (Greenwich Mean Time) is the older astronomical standard based on the sun's position at Greenwich, England. UTC drifts by less than a second per year; GMT can drift by larger amounts. For all practical purposes — including your code — treat them as identical.

Always store as UTC. Convert to the user's local timezone only when displaying. This avoids every class of timezone bug — DST transitions, users traveling across time zones, summer time policy changes, daylight saving extensions like the US 2007 change. The IANA timezone database handles the conversion for you in every modern programming language. Storing local time and trying to recover UTC later is a recipe for silent data corruption.

No, and that's a feature. Unix time is a count of seconds since 1970-01-01 UTC — there are no DST rules, no time zones, no leap seconds in the count (the timestamps just repeat during a leap second). DST is a display convention that's applied when you convert Unix time to a local time format. The conversion handles it; the storage doesn't need to.

An IANA timezone is a name like America/New_York, Europe/London, or Asia/Tokyo from the open-source IANA Time Zone Database. The name encodes all of the DST rules, historical changes, and current behavior for that zone. Always use IANA names instead of fixed UTC offsets (UTC-5) — fixed offsets don't update for DST and silently produce wrong results half the year.

Some countries chose to offset by 30 or 45 minutes from UTC rather than a whole hour. India is UTC+5:30. Nepal is UTC+5:45. Iran is UTC+3:30. Parts of Australia are at +8:45 or +9:30. There's no single reason — it's usually a historical compromise between solar noon position and political preference. If your code handles UTC offsets as integer hours, it will be wrong for all of these.

An LDAP timestamp (also called a Microsoft FILETIME or NT timestamp) is the number of 100-nanosecond intervals since January 1, 1601 UTC. It's used in Active Directory, Windows event logs, NTFS filesystem timestamps, and the Windows registry. Values are typically 18-digit numbers. Use our LDAP timestamp converter for the back-and-forth.

A .NET DateTime tick is one 100-nanosecond interval since 0001-01-01 00:00:00 UTC (year 1, January 1). The DateTime.Ticks property in C# returns this value as a 64-bit integer. Values for current dates are around 6.4 × 10¹⁷ (18 digits). See our .NET ticks converter.

Discord uses a tag-based syntax: <t:1750000000:F> where the number is a standard Unix timestamp in seconds and the letter at the end controls how Discord renders it. F is full date and time, R is relative ("2 hours ago"), t is time-only, etc. Our Discord timestamp generator lets you pick a date and gives you the tag to paste.

When Excel exports dates to CSV or shows them as 5-digit numbers, it's using the OADate format — days since 1900-01-00 (a phantom reference date that exists because of Excel's intentional 1900 leap year bug). To convert to a Unix timestamp: (excel_value - 25569) × 86400 = unix_seconds. Our Excel OADate converter handles this both ways.

GPS time is seconds since January 6, 1980 at 00:00:00 UTC. Unlike UTC, GPS time does not include leap seconds — it's a continuous count. As of 2026, GPS time is 18 seconds ahead of UTC because that many leap seconds have been added to UTC since 1980. Our GPS time converter handles the leap-second adjustment automatically.

The Julian Day Number is the integer count of days since 4713 BC January 1 at noon UTC. It's used in astronomy for representing dates as a single continuous number across all of recorded history. The current Julian Day is around 2,461,000. Modified Julian Day (MJD) subtracts 2,400,000.5 to give a smaller, more manageable number for recent dates. See our Julian Day converter.

On January 19, 2038 at 03:14:08 UTC, the Unix timestamp will reach 2,147,483,648 — one more than the maximum value of a signed 32-bit integer. Systems that store timestamps as 32-bit signed integers will overflow and wrap around to a negative number, which gets interpreted as December 13, 1901. Any code that does timestamp arithmetic with 32-bit integers will silently produce wrong results past this date. See our full Year 2038 explainer.

Probably not, if you're using modern infrastructure. 64-bit Linux, JavaScript (uses 53-bit-safe doubles), Python (arbitrary precision), Java (always 64-bit long), modern databases with native timestamp types, and recent versions of every major language are all fine. The bug is in legacy 32-bit systems, explicit casts like (int)time(NULL) in C, and serialization formats (protobuf int32, Avro int, etc.) that aren't 64-bit.

Audit your database columns for 32-bit integer timestamp columns and migrate them to BIGINT (64-bit). Search your codebase for explicit casts from wide types to 32-bit ints. Check that your serialized formats (protobuf, Avro, etc.) use 64-bit time fields. Our migration guide walks through the practical steps.

When you click "Copy share link" on any converter page, your current input is encoded into the URL as a query parameter. Anyone who opens that URL sees the same value loaded into the same field. The URL updates as you type (so you can also just copy the address bar). Sharing requires explicit action — nothing is uploaded or stored on a server; the link encodes the data itself.

The data in the URL is exactly what you can see. There's no server-side storage. If you don't share the link, no one else sees it. If you do share it, anyone with the link sees the same value you encoded. For sensitive timestamps (e.g., user activity logs, security investigations) consider whether the URL might be logged in browser history, server logs, or chat apps before you share.

The batch converter handles up to 10,000 timestamps per input. Encoding that volume of data in a URL would exceed most browsers' URL length limits (typically 2,048 characters) and most server log limits. For sharing batch results, use the CSV or JSON export buttons instead.