> timestamp | epoch | convert <

A: A timestamp is a value that marks a specific moment in time. In computing, the most common form is a Unix timestamp — an integer counting seconds since January 1, 1970 UTC. Other systems use ISO 8601 strings (2024-03-25T00:00:00Z), RFC 2822 (Mon, 25 Mar 2024 00:00:00 GMT), Windows FILETIME, or database-specific formats. The Unix integer form is preferred for storage, sorting, and arithmetic because it's compact and timezone-neutral.

A: A Unix timestamp is the number of seconds that have elapsed since January 1, 1970 00:00:00 UTC. It is a simple integer value used universally in computing to represent a specific point in time, independent of timezones.

A: Epoch time is another name for Unix timestamp. The "epoch" refers to the reference point: January 1, 1970 00:00:00 UTC. All Unix timestamps are measured as the number of seconds since this epoch.

A: The live counter at the top of this page displays the current Unix timestamp and updates every second. You can copy it directly, or use it as a reference when debugging time-sensitive systems. Programmatically: Math.floor(Date.now()/1000) in JavaScript, int(time.time()) in Python, date +%s on Linux/macOS.

A: Paste the timestamp into the TIMESTAMP INPUT field and click [TO DATE]. The tool outputs the date in ISO 8601, RFC 2822, UTC, local time, and relative format ("5 minutes ago"). If the value is 13 digits long, switch the unit toggle to MILLISECONDS first.

A: Enter the date in the DATE INPUT field (ISO-style YYYY-MM-DD HH:MM:SS works) and click [TO TIMESTAMP]. The local timezone is applied by default — switch the output between seconds and milliseconds as needed.

A: The Year 2038 problem (Y2K38) occurs because many systems store Unix timestamps as 32-bit signed integers, which can only represent times up to January 19, 2038 03:14:07 UTC. After that, the value overflows. Modern systems use 64-bit integers to avoid this.

A: Unix timestamps in seconds are 10 digits long (e.g., 1711324800), while millisecond timestamps are 13 digits (e.g., 1711324800000). JavaScript's Date.now() returns milliseconds, while most Unix/Linux tools use seconds. Some APIs also use microseconds (16 digits) or nanoseconds (19 digits).

A: Yes, negative Unix timestamps represent dates before January 1, 1970. For example, -86400 represents December 31, 1969. This is useful for representing historical dates in computing systems.

A: Unix time / Epoch time are two names for the same thing: an integer count of seconds since 1970-01-01 UTC. ISO 8601 is a string format for dates and times (2024-03-25T13:45:30Z) designed for human readability and unambiguous parsing. Unix time is easier for arithmetic and sorting; ISO 8601 is easier to read in logs and JSON APIs. Our converter shows both formats side by side.

A: Unix timestamps are always in UTC. The integer itself has no timezone — it is an absolute instant. A timezone is only applied when you display the timestamp as a human-readable date. This is why Unix time is so reliable for cross-system coordination: the same integer means the same moment everywhere.

A: Yes. NTP uses 1900-01-01 UTC. Windows FILETIME uses 1601-01-01 UTC and counts 100-nanosecond intervals. Mac HFS+ used 1904-01-01. Excel uses 1900-01-00 (with a famous leap-year bug). If you see a timestamp that is very far from today's Unix value, check that it is actually a Unix timestamp and not one of these variants.

A:
JavaScript: Math.floor(Date.now() / 1000) for seconds, Date.now() for milliseconds.
Python: import time; int(time.time()) or datetime.now(timezone.utc).timestamp().
PHP: time() (seconds) or microtime(true) * 1000 (ms).
Go: time.Now().Unix() or time.Now().UnixMilli().
Rust: SystemTime::now().duration_since(UNIX_EPOCH)?.as_secs().
Java: Instant.now().getEpochSecond() or System.currentTimeMillis().
Ruby: Time.now.to_i.
Bash: date +%s (macOS: gdate +%s if GNU coreutils installed).

A: new Date(1711324800 * 1000) — multiply by 1000 because JavaScript's Date takes milliseconds. Examples:

const ts = 1711324800;
const d = new Date(ts * 1000);
d.toISOString();          // "2024-03-25T00:00:00.000Z"
d.toUTCString();          // "Mon, 25 Mar 2024 00:00:00 GMT"
d.toLocaleString();       // browser-local format

A:
Python: datetime.fromtimestamp(1711324800, tz=timezone.utc) → timezone-aware datetime. Use tz=None for local time. Reverse: int(dt.timestamp()).
Java: Instant.ofEpochSecond(1711324800) → 2024-03-25T00:00:00Z. Use ZonedDateTime.ofInstant(instant, zone) for a specific zone. Reverse: instant.getEpochSecond().
Go: time.Unix(1711324800, 0).UTC() (or .Local()). Reverse: t.Unix(). The second argument is nanoseconds — pass 0 if you only have seconds.

A: Check the digit count:
• 10 digits (e.g., 1711324800) → seconds, 2024-era.
• 13 digits (e.g., 1711324800000) → milliseconds.
• 16 digits → microseconds (common in Python's time.time_ns() / 1000, Cassandra, Kafka).
• 19 digits → nanoseconds (Go's time.UnixNano(), InfluxDB).
Rule of thumb: if the number divided by 10⁹ looks like a reasonable "years since 1970", you have seconds. If dividing by 10¹² looks reasonable, it's milliseconds. Many APIs (e.g., Stripe in seconds, Slack with dotted seconds, Twitter in milliseconds) differ — always check the docs.

A: ISO 8601 is a textual format: 2024-03-25T00:00:00Z (or 2024-03-25T02:00:00+02:00 for a non-UTC zone). It is human-readable, sortable as a string, and carries timezone info explicitly via Z (zero offset) or ±hh:mm. RFC 3339 is a stricter subset of ISO 8601 used in JSON APIs. Unix time is a pure integer with no timezone — it's always UTC. Store ISO 8601 when humans need to read the value (logs, config, JSON), and Unix integers when you need compact storage, range queries, or math.

A: Depends on storage width:
• 32-bit signed int: -2,147,483,648 (1901-12-13 20:45:52 UTC) to 2,147,483,647 (2038-01-19 03:14:07 UTC). This is the Y2038 cliff.
• 32-bit unsigned: 0 to 4,294,967,295 (2106-02-07 06:28:15 UTC).
• 64-bit signed: ±9.2×10¹⁸ seconds — roughly ±292 billion years, enough for any conceivable real-world use.
• JavaScript Date: ±8.64×10¹⁵ ms (±275,760 years from 1970). Beyond that you get Invalid Date.

A: The golden rule: store UTC, render local. A Unix timestamp is always UTC. Only when you display it do you apply a timezone:
• JavaScript: new Date(ts*1000).toLocaleString('en-US', { timeZone: 'America/New_York' }).
• Python: datetime.fromtimestamp(ts, ZoneInfo('Asia/Tokyo')).
• PostgreSQL: store TIMESTAMPTZ, query with AT TIME ZONE 'Europe/Berlin'.
Never store "local" timestamps — you will lose track of which zone was active during DST transitions. Always serialize with a zone indicator if you're not using a pure Unix integer.

A: RFC 2822 (updated by RFC 5322) defines the email date header format: Mon, 25 Mar 2024 00:00:00 +0000 (day name, day month year, time, zone offset). It's also what HTTP uses in headers like Last-Modified and Expires. Convert from ISO: new Date('2024-03-25T00:00:00Z').toUTCString(). Convert to ISO: new Date('Mon, 25 Mar 2024 00:00:00 GMT').toISOString(). The day name is recommended but optional; the zone offset should be +0000 or GMT, not the obsolete UT/PDT forms.

A: Common causes:
• Seconds vs milliseconds confusion: a 13-digit value interpreted as seconds yields a date around the year 55,000; a 10-digit value interpreted as milliseconds yields a date in 1970.
• Timezone mismatch: the server stored UTC but you're rendering in local without converting.
• Implicit local parsing: new Date('2024-03-25') is UTC, but new Date('2024-03-25 00:00:00') is local — results can differ by several hours.
• Windows FILETIME or .NET Ticks mistaken for Unix: FILETIME is 18 digits in 100-ns intervals since 1601; subtract the epoch difference and divide before treating as Unix.
• Spreadsheet import: Excel dates are day counts since 1900 (with the famous 1900 leap-year bug), not Unix seconds.

A: They don't, by design. POSIX specifies that Unix time counts a fixed 86,400 seconds per day and ignores leap seconds. When UTC inserts a leap second (e.g., 2016-12-31 23:59:60), most Unix systems either repeat the previous second or "smear" the adjustment across several hours (Google/AWS leap smear). Consequence: for most applications Unix time is close enough to UTC to be treated as equivalent, but for scientific timing you need TAI (International Atomic Time) or a monotonic clock. The IERS has announced plans to abolish leap seconds by 2035.

A:
PostgreSQL: SELECT to_timestamp(1711324800); → 2024-03-25 00:00:00+00. Reverse: EXTRACT(EPOCH FROM now()).
MySQL / MariaDB: SELECT FROM_UNIXTIME(1711324800); and UNIX_TIMESTAMP(NOW()).
SQLite: SELECT datetime(1711324800, 'unixepoch'); and strftime('%s', 'now').
SQL Server: DATEADD(s, 1711324800, '1970-01-01') and DATEDIFF(s, '1970-01-01', GETUTCDATE()).
Oracle: TIMESTAMP '1970-01-01 00:00:00 UTC' + NUMTODSINTERVAL(1711324800, 'SECOND').

A: Both store dates as serial numbers (days since 1899-12-30 for Excel), not Unix seconds. Convert Unix to Excel: = (A1 / 86400) + 25569 where A1 is Unix seconds. Reverse (Excel to Unix): = (A1 - 25569) * 86400. The 25569 constant is the number of days between Excel's epoch (1900-01-00, including the leap-year bug) and the Unix epoch (1970-01-01). Google Sheets uses the same convention. Format the result cell as a date or apply TEXT(B1, "yyyy-mm-dd hh:mm:ss").

A:
• ISO 8601 is the broad standard — it allows week dates (2024-W13), ordinal dates (2024-084), fractional seconds, basic format without dashes, and more.
• RFC 3339 is a stricter, unambiguous subset used in internet protocols. Always YYYY-MM-DDTHH:MM:SS[.fff]Z or with ±HH:MM offset. No week/ordinal forms.
• JSON has no native date type. Most APIs (Stripe, GitHub, OpenAPI) use RFC 3339 strings, while some use Unix seconds. JSON.stringify(new Date()) produces ISO 8601 with milliseconds and Z: "2024-03-25T00:00:00.000Z".
For interoperability, prefer RFC 3339 in UTC for strings and Unix seconds (integer) when size matters.