Epoch / Unix Timestamp Converter
Convert Unix timestamps to human-readable dates and back, with timezone support.
Current Unix Timestamp
seconds since Jan 1, 1970 00:00:00 UTC
→ → Timestamp to Date
→ → Date to Timestamp
What Is a Unix Timestamp?
A Unix timestamp (also called Epoch time, POSIX time, or Unix time) is the number of seconds that have elapsed since January 1, 1970, 00:00:00 UTC — a reference point known as the Unix Epoch. This system was introduced with the Unix operating system in the late 1960s and has since become the universal, language-agnostic standard for representing points in time in computing. The Unix Epoch was chosen pragmatically (it preceded the widespread adoption of Unix by about a year), and while it was briefly controversial, it has proven remarkably durable: as of mid-2025, the current Unix timestamp is approximately 1,748,000,000 — a 10-digit number that comfortably fits in a 32-bit signed integer until January 19, 2038, and in a 64-bit integer for over 292 billion years.
The defining characteristic of Unix timestamps — and the reason they remain the dominant time representation in software — is that they are timezone-agnostic. The value 1700000000 represents the exact same absolute moment worldwide, regardless of whether the observer is in Berlin, Tokyo, or New York. This eliminates an entire class of distributed-system bugs: two servers in different data centers comparing Unix timestamps are comparing the same reference frame, with no ambiguity about DST offsets, UTC offsets, or local timezone conventions. This is why every major database, programming language, operating system, and API uses Unix timestamps internally, converting to human-readable local time only at the display layer.
In practice, software engineers encounter two closely related timestamp formats: second-precision timestamps (10 digits, e.g., 1700000000) and millisecond-precision timestamps (13 digits, e.g., 1700000000000). JavaScript's Date.now() and most browser APIs return milliseconds; Linux time(), PostgreSQL, and most server-side languages default to seconds; some financial and distributed tracing systems use microseconds (16 digits) or nanoseconds (19 digits). The ISO 8601 standard (and its internet profile RFC 3339) provides the human-readable complement: strings like 2025-04-15T14:30:00Z or 2025-04-15T14:30:00+02:00 that include explicit timezone information. XRechnung and ZUGFeRD use the YYYY-MM-DD subset of ISO 8601 for invoice dates, delivery dates, and payment due dates — never Unix timestamps — because human-readable strings are required for legal documents.
How to Use This Converter
- Live Epoch Counter — The large counter at the top shows the current Unix timestamp in seconds, updating every second. Click "Copy" to grab the current timestamp for use in a database query, API call, or log search.
- Timestamp to Date — Paste a Unix timestamp (seconds or milliseconds — the tool auto-detects based on digit count) and click Convert to see the human-readable date and time in your selected timezone.
- Date to Timestamp — Select a date and time using the datetime picker and convert it to a Unix timestamp in both seconds and milliseconds. Useful for constructing API query parameters or database WHERE clauses with time boundaries.
- Timezone Selector — Choose from 8 common timezones including UTC, Europe/Berlin (with automatic CET/CEST handling), America/New_York, America/Los_Angeles, Asia/Tokyo, and others. All DST transitions are handled automatically by the browser's Intl API.
All timestamp calculations run entirely in your browser using JavaScript's native Date object and Intl.DateTimeFormat API. No data is transmitted to any server.
How It Works
Timestamps are processed using JavaScript's native Date object. The input string is first inspected by digit count: 10 digits (range 1,000,000,000 to 9,999,999,999) are treated as seconds and multiplied by 1000 before constructing the Date object; 13 digits are treated as milliseconds directly. Edge cases like 0 (Unix Epoch) and negative values (pre-1970) are handled by the Date constructor. The Intl.DateTimeFormat API — which uses the IANA timezone database built into the browser — formats the resulting moment in the selected timezone, automatically applying the correct UTC offset and DST rules for the specific date in question.
For the reverse conversion (date to timestamp), the tool reads the datetime-local input as an ISO 8601 local time string (e.g., 2025-04-15T14:30). Since datetime-local inputs have no timezone information, our tool interprets the value as being in the currently selected timezone. It constructs a Date object by applying the selected timezone offset to get the UTC equivalent, then calls getTime() to retrieve the millisecond timestamp, and divides by 1000 for the seconds timestamp. Both values are displayed so you can copy whichever precision your target system expects.
The live counter uses setInterval with a 1000 ms interval to call Math.floor(Date.now()/1000) each second and update the display. Because Date.now() reads the browser's system clock, the displayed timestamp matches your computer's clock — not a remote NTP server. If your system clock is significantly drifted from UTC (more than a few seconds), the displayed timestamp will reflect that drift. For production systems, keep your servers' clocks synchronized using NTP or PTP (precision time protocol).
Use Cases
Database Query Debugging
SQL and NoSQL queries often involve timestamp comparisons. PostgreSQL stores TIMESTAMPTZ values internally as Unix microseconds since 2000-01-01, while MySQL TIMESTAMP stores seconds since 1970. When inspecting raw database values with SELECT EXTRACT(EPOCH FROM created_at) or looking at MongoDB's ISODate internals, our converter translates the raw integer to a human-readable datetime instantly.
REST API and Webhook Debugging
GitHub, Stripe, AWS CloudWatch, and hundreds of other APIs return Unix timestamps in JSON payloads — for created_at, updated_at, expires_at, last_seen, and similar fields. Paste the timestamp value directly from a JSON response to see the corresponding date without mentally calculating the conversion.
Log File and Observability Analysis
Nginx access logs, syslog entries, Datadog and Grafana metrics, and distributed tracing spans use Unix timestamps or millisecond timestamps extensively. When correlating an incident across multiple log sources, converting timestamps to a common timezone (preferably UTC) is essential. Our tool also helps when checking whether a token or session has expired by comparing its exp field (a Unix timestamp) against the current time.
XRechnung and Invoice Date Conversion
XRechnung mandates ISO 8601 date strings (YYYY-MM-DD) for BT-2 (invoice issue date), BT-72 (delivery period start), and BT-9 (payment due date). If your billing system generates Unix timestamps, our converter produces the exact ISO 8601 date string required for the XML. The UTC tab is the correct choice for date conversion — XRechnung dates reference calendar dates without time components, and converting from the UTC date avoids DST-related off-by-one day errors.
Example: Timestamp Conversion
Here is how Unix timestamp 1700000000 converts to different timezone representations. All four lines refer to the same absolute moment in time — only the local clock display differs:
Unix Timestamp (seconds): 1700000000 Unix Timestamp (milliseconds): 1700000000000 Timezone conversions: UTC: 2023-11-14T22:13:20Z Europe/Berlin: 2023-11-15T00:13:20+01:00 (CET, UTC+1 in November) America/New_York: 2023-11-14T17:13:20-05:00 (EST, UTC-5) Asia/Tokyo: 2023-11-15T07:13:20+09:00 (JST, UTC+9) As XRechnung invoice date (UTC calendar date): 2023-11-14 Note: Berlin date is 2023-11-15 — timezone matters for date-only values!
Notice that the calendar date differs between UTC (Nov 14) and Berlin (Nov 15) because the timestamp falls after midnight Berlin time. For XRechnung, always derive the invoice date from the UTC representation to avoid off-by-one day bugs.
Tips & Limitations
Tips
- Our tool automatically detects whether a timestamp is in seconds (10 digits) or milliseconds (13 digits). If you see an implausible date (year 1970 or year 59999), you may have the wrong unit — try dividing or multiplying by 1000.
- Always store timestamps in UTC in databases and application state. Convert to local timezone only at the display layer — this is the single most effective practice for eliminating DST-related bugs in distributed systems.
- For XRechnung-compatible date strings (YYYY-MM-DD), use the UTC conversion result. If the timestamp falls after midnight UTC but before midnight in the invoice's local timezone, the dates will differ — this is a common source of off-by-one-day errors in invoice generation.
- The live counter can be copied and used directly as a WHERE clause boundary in SQL (WHERE created_at > 1700000000), as a cache-busting query parameter (?v=1700000000), or as a log search timestamp.
Limitations
- The tool supports 8 common timezones. For other IANA timezones (e.g., Asia/Kolkata, Pacific/Auckland), use a programming language's datetime library or the browser's native Intl.DateTimeFormat with the full IANA name.
- Nanosecond timestamps (19 digits, used in high-frequency trading, network protocols, and some CNCF observability tools) are not supported. Use specialized libraries (e.g., Python's time.time_ns(), Go's time.Now().UnixNano()) for nanosecond precision.
- Negative timestamps (representing dates before January 1, 1970) are supported by JavaScript's Date object and our converter, but many legacy systems, 32-bit integers, and old databases may not handle them correctly.
- Accuracy depends on the browser's system clock, which is typically synchronized to NTP but may drift by a few hundred milliseconds. For millisecond-precision requirements in production, synchronize your system clock using an NTP client (chrony, ntpd) or a cloud provider's time service.
Frequently Asked Questions
What is the Year 2038 problem and does it affect modern systems?
Systems that store Unix timestamps as 32-bit signed integers will overflow on January 19, 2038, at 03:14:07 UTC — the moment the value 2,147,483,647 (the maximum positive 32-bit integer) is exceeded. The timestamp wraps to -2,147,483,648, which represents December 13, 1901, causing date calculations to produce wildly incorrect results. Modern 64-bit systems using int64 (signed 64-bit integers) are safe until the year 292,277,026,596 CE. Risk areas include legacy embedded systems (industrial controllers, older routers), MySQL TIMESTAMP columns (which use 32-bit storage and have a max value of 2038-01-19 03:14:07), and any application code that stores timestamps in a 32-bit integer type. Audit your infrastructure if any component uses MySQL TIMESTAMP, C int32_t for time_t, or embedded Linux on 32-bit hardware.
What is the difference between seconds and milliseconds timestamps?
A seconds-precision Unix timestamp has 10 digits (range: 0 to ~9.9 billion, covering years 1970 to 2286). A milliseconds-precision timestamp has 13 digits (the seconds value multiplied by 1000, plus the milliseconds). JavaScript's Date.now() returns milliseconds. Unix system calls (time(), gettimeofday()), Python's time.time(), and most database systems use seconds by default. Redis EXPIREAT commands accept seconds; Redis PEXPIREAT accepts milliseconds. Our tool auto-detects the unit from the digit count — but if you receive an unexpected date, verify the unit assumption.
Why do timestamps always reference UTC?
UTC (Coordinated Universal Time) provides a single, unambiguous reference frame that all clocks worldwide can relate to. By storing and transmitting times in UTC and converting to local time only for display, systems avoid the three most common time-related bugs: (1) DST transition ambiguity — clocks go back one hour in autumn, making a one-hour window of local times repeat; (2) timezone rule changes — governments modify timezone rules, and historical data must reflect the rules in effect at the time; (3) cross-timezone comparison errors — comparing two local timestamps from different zones without accounting for offsets. IETF RFC 3339 and ISO 8601 both recommend UTC or explicit UTC offset notation for all time values in protocols.
Can Unix timestamps represent dates before 1970?
Yes — negative Unix timestamps represent instants before the Unix Epoch. For example, -86400 represents 1969-12-31T23:59:59Z (one second before midnight on December 31, 1969), and -2208988800 represents 1900-01-01T00:00:00Z. JavaScript's Date object and most 64-bit libraries handle negative timestamps correctly. However, many database systems (MySQL TIMESTAMP, early PostgreSQL versions) do not support negative timestamps — in those cases, use a DATE or DATETIME column type instead. Historical dates in financial and legal records (before 1970) are typically stored as ISO 8601 strings, not Unix timestamps.
What is the difference between Unix time and ISO 8601?
Unix time is an integer (or decimal for sub-second precision) counting seconds since 1970-01-01T00:00:00Z. It is compact, arithmetic-friendly, and timezone-free. ISO 8601 is a human-readable string format standardized by ISO for date and time representation: 2025-04-15 (date only), 2025-04-15T14:30:00Z (UTC datetime), or 2025-04-15T16:30:00+02:00 (datetime with explicit offset). RFC 3339 is an internet profile of ISO 8601 used in IETF protocols and APIs (the two are nearly equivalent). XRechnung uses the YYYY-MM-DD date format — a subset of ISO 8601 — for all invoice date fields, because legal documents require human-readable, timezone-unambiguous dates.
How does Daylight Saving Time (DST) affect timestamp conversions?
Unix timestamps themselves are never affected by DST — they are always UTC-based absolute counts. DST only matters when you convert a timestamp to a local time for display. The same Unix timestamp may display as 14:00 CET (UTC+1) in January and 15:00 CEST (UTC+2) in July in the Europe/Berlin timezone, because Germany observes DST. If you compute a 'midnight Berlin time' timestamp for a date in summer, you need to use UTC+2, not UTC+1. Our tool's Intl.DateTimeFormat backend uses the full IANA timezone database and automatically applies the correct DST offset for the specific date — you do not need to know whether a given date is in CET or CEST.
What timestamp format does XRechnung use?
XRechnung uses ISO 8601 date strings in the YYYY-MM-DD format for BT-2 (invoice issue date), BT-72/73 (delivery period start/end), BT-9 (payment due date), and BT-26 (seller contact date). These are calendar dates without time components. XRechnung does not use Unix timestamps in any field. When generating XRechnung from a billing system that stores Unix timestamps, convert the timestamp to a UTC calendar date (YYYY-MM-DD) to get the correct ISO 8601 date string. Important: if the timestamp falls after midnight UTC but before midnight in the business's local timezone, the UTC date and local date may differ — use the UTC date consistently to avoid ambiguity across cross-border transactions.
How precise is a Unix timestamp?
A standard Unix timestamp in seconds provides 1-second precision — sufficient for most business and logging use cases. Millisecond timestamps (used in JavaScript, many REST APIs, and Java's System.currentTimeMillis()) provide 1 ms precision. High-resolution timestamps in Linux (clock_gettime(CLOCK_REALTIME)) and Go's time.Now().UnixNano() provide nanosecond resolution, though the actual hardware clock precision is typically 1–100 microseconds. For financial transactions and high-frequency trading, nanosecond timestamps and PTP (Precision Time Protocol) synchronization are standard. For web application development and API work, millisecond precision is more than adequate.
What is the Unix timestamp for a specific calendar date and time?
Use the 'Date to Timestamp' section: select your target date and time in the datetime picker, choose the appropriate timezone, and click Convert. The tool returns both the seconds timestamp and the milliseconds timestamp. Alternatively, in JavaScript: new Date('2025-12-31T00:00:00Z').getTime() / 1000 gives the UTC midnight seconds timestamp for December 31, 2025. In Python: import datetime; datetime.datetime(2025, 12, 31, 0, 0, 0, tzinfo=datetime.timezone.utc).timestamp(). In SQL (PostgreSQL): SELECT EXTRACT(EPOCH FROM TIMESTAMP WITH TIME ZONE '2025-12-31 00:00:00+00').
Can I store timestamps in a database as Unix integers?
It depends on your needs. Native timestamp types (TIMESTAMP WITH TIME ZONE in PostgreSQL, DATETIME(6) in MySQL 5.6+) are recommended because they integrate with the database's date arithmetic functions (DATE_ADD, DATEDIFF, date_trunc), are displayed readably in query results, and correctly support timezone-aware comparisons. However, storing UTC Unix timestamps in a BIGINT column is a valid, highly portable alternative used in many high-performance systems — it avoids any DST or timezone handling at the database level and works identically across PostgreSQL, MySQL, SQLite, and DynamoDB. Just document your column as 'UTC Unix timestamp in seconds' or 'milliseconds', and add the unit conversion at the application layer.