⏰ Unix Timestamp Converter - Convert timestamps

🕐

Current Unix Timestamp

Milliseconds:

{{ currentTime.unix }}000

ISO 8601:

📝 Input Text

Detected format: {{ detectedFormat }}

⚡ Quick Actions

📤 Conversion Results

Unix Timestamp (seconds):

{{ results.unix }}

Milliseconds (JavaScript):

{{ results.milliseconds }}

ISO 8601 (UTC):

{{ results.iso }}

Human Readable (Local):

{{ results.local }}

Human Readable (UTC):

{{ results.utc }}

📊 Time Analysis

Day of Week: {{ results.analysis.dayOfWeek }}

Day of Year: {{ results.analysis.dayOfYear }}

Week of Year: {{ results.analysis.weekOfYear }}

Quarter: {{ results.analysis.quarter }}

Is Leap Year: {{ results.analysis.isLeapYear ?'Yes' :'No' }}

Days in Month: {{ results.analysis.daysInMonth }}

Timezone Offset: {{ results.analysis.timezoneOffset }}

Relative: {{ results.analysis.relative }}

⚠️ {{ error }}

ℹ️ About Unix Timestamp Conversion

A Unix timestamp, also called POSIX time or epoch time, counts elapsed seconds from 1970-01-01 00:00:00 UTC and carries no timezone of its own. This converter turns epoch seconds or JavaScript milliseconds into ISO 8601, UTC, and local date strings, parses a date string back into a timestamp, and adds a calendar breakdown of the instant. It is built for checking API parameters, decoding database fields, comparing log events from different servers, testing cron or queue schedules, and debugging frontend code that stores dates as millisecond timestamps.

POSIX time does not count leap seconds, so it fits ordinary Unix, web, and application timestamps rather than TAI, GPS time, or leap-second accounting. Web and API timestamps commonly use RFC 3339 date-time strings, a constrained Internet profile of ISO 8601. Browser-side handling is based on the ECMAScript Date time value, measured in milliseconds from the same UTC epoch.

Supported inputs

Unix seconds: exactly 10 digits, such as 1704067200; pad early values, for example 0000000000 for the epoch itself.
JavaScript milliseconds: exactly 13 digits, such as 1704067200000.
ISO 8601 / RFC 3339 date-times: YYYY-MM-DDTHH:MM:SS with an optional fraction and a Z suffix or numeric offset such as +02:00. Without a designator the time is read as local time.
Other date strings: anything the JavaScript Date parser accepts, such as 2024-01-01 (date-only, read as UTC) or Mon, 01 Jan 2024 00:00:00 GMT.
Quick Actions: insert the start of the current year, month, or day at local midnight in your browser's timezone. A separate button in the live panel inserts the current Unix seconds.

Leading and trailing whitespace is ignored, and the detected format is shown under the input as you type.

Output

Unix Timestamp (seconds): whole seconds, rounded down.
Milliseconds (JavaScript): the same instant in milliseconds.
ISO 8601 (UTC): the toISOString() form with millisecond precision and a Z suffix.
Human Readable (Local) and (UTC): the browser locale string in your timezone, and the toUTCString() HTTP-date form such as Mon, 01 Jan 2024 00:00:00 GMT.
Time Analysis: day of week, day of year, week of year, quarter, leap-year flag and days in month, all read from the local calendar, plus your UTC offset (the API reports the server's) and a relative phrase such as 3 days ago.

Each conversion result has its own copy button (the Time Analysis fields do not), and a live panel above the converter shows the current Unix timestamp, refreshed every second. The API returns the same data as JSON: success, detectedFormat, and a results object with unix, milliseconds, iso, local, utc, and analysis.

Example

Input 1704067200 is detected as Unix seconds and produces 2024-01-01T00:00:00.000Z (ISO 8601), 1704067200000 (milliseconds), and Mon, 01 Jan 2024 00:00:00 GMT (UTC), which are the same in every timezone. The analysis follows your local calendar instead: in UTC or a zone ahead of it the instant reports Monday, day 1 of the year, Q1, leap year, 31 days in the month, while a browser in New York is still on 31 December 2023 and reports Sunday, day 365, Q4, not a leap year. Entering 2024-01-01T02:00:00+02:00 converts back to the same 1704067200, because the offset is folded into the UTC instant.

Limitations

Numeric input must have exactly 10 or 13 digits. Microsecond and nanosecond values, signed numbers, and decimals are not treated as timestamps; short numbers fall through to the date parser and may be read as a year.
Dates before 1970 cannot be entered as negative numbers, only as date strings such as 1969-12-31T00:00:00Z (which yields -86400).
There is no timezone picker: output is shown in UTC and in the browser's own timezone (the server's for the API). Use the Time Zone Converter to render other zones.
Week of year is a simple ceil(dayOfYear / 7), not the ISO 8601 week number, and day of year is measured from local midnight with a fixed 24-hour day, so it is off by one within an hour of local midnight on any day whose UTC offset differs from the offset in force on 1 January: one too low in the first hour of a day that runs ahead of the January offset (daylight saving in most zones), one too high in the last hour of a day that runs behind it. Week of year inherits that error.
The Unix Epoch quick action converts 1 January 1970 through your local timezone, so it does not insert a usable 10-digit value; type 0000000000 to convert the epoch itself.
Leap seconds are not represented, local names and offsets follow the browser's copy of the IANA Time Zone Database, and free-form date strings depend on the JavaScript engine's parser, so they may differ between browsers.

Browser or server processing

Conversion runs entirely in your browser through the compiled logic module (timestamp-converter.logic.js); nothing you type is sent to our server. The public API endpoint executes the same module on the server through Node.js, so unix, milliseconds, iso and utc match. The local string, timezoneOffset and every Time Analysis calendar field (day of week, day of year, week, quarter, leap year, days in month) are computed in the server's timezone rather than yours, and relative is measured against the server clock unless you pass now in milliseconds. Anonymous API calls are limited to 60 requests per minute.

FAQ

Is the timestamp in seconds or milliseconds?

The tool decides by digit count: 10 digits are seconds, 13 digits are milliseconds. A value that lands in 1970 or thousands of years in the future was usually multiplied or divided by 1000 somewhere; both representations are always shown so you can compare them.

Why is my date off by one hour?

An ISO 8601 date-time without a Z or offset is read as local time, and the Human Readable (Local) line uses your browser's current timezone, which shifts across daylight-saving transitions. Add Z or an explicit offset to the input and read the ISO 8601 (UTC) line for an unambiguous instant.

What happens in 2038?

Signed 32-bit Unix time overflows after 2147483647, which is 2038-01-19 03:14:07 UTC (the Year 2038 problem). This converter uses 64-bit JavaScript time values, so 2147483648 converts to 2038-01-19T03:14:08.000Z and 10-digit input works up to 9999999999 (year 2286).

References

API Usage Example:

POST /api/tools/convert/timestamp
Content-Type: application/json

{
    "input": "1234567890"
}