Timestamp Batch Converter

Overview

A column of numbers in a log file, a long integer returned by an API, a created_at value in a database: these are almost always Unix timestamps, but some are ten digit seconds and others are thirteen digit milliseconds. Applying one formula to both produces results wrong by a factor of a thousand. This converter infers the unit from the digit count, treating ten digits as seconds and thirteen as milliseconds, and lets you force either unit when the length looks unusual or the value is negative. Each line is converted independently and errors are isolated, so a malformed row is counted as unrecognised while the rest still convert. Output gives four values per row: the original, local time in the chosen zone, UTC with a Z suffix, and the Unix value in both seconds and milliseconds. Going the other direction, paste dates and get timestamps back for bulk loading into an API.

Features

• Both directions in one tool: timestamps to dates, or dates to timestamps, toggled by a dropdown
• Unit detection by digit count for ten digit seconds and thirteen digit milliseconds, with manual override
• Timezone selection between UTC+8 and UTC, where local time follows the chosen zone and the UTC column always carries Z
• Four values per row: source, local time, UTC, and the Unix value in seconds and milliseconds
• Line-level error isolation: bad rows are counted separately and never abort the batch
• Five column CSV export that imports directly into a spreadsheet for timeline work

How to use

1. Pick the direction: numbers to dates, or dates to numbers
2. Choose the timezone, UTC+8 for domestic logs and UTC for cross-region comparison
3. Leave the unit on automatic unless the digit count is odd or the value is negative
4. Paste the values one per line, or enter dates in YYYY-MM-DD HH:MM:SS form
5. Read the table and the summary at the top, then copy the local column or export CSV

Notes

• The ten versus thirteen digit split is the primary unit signal; nanosecond timestamps of seventeen digits are out of scope
• Negative values are treated as before 1970, and automatic mode conservatively reads them as seconds, so specify the unit for cross-epoch data
• Date rows must be written as 2026-11-11 or 2026-11-11 09:30:00; slashes and two digit years are not recognised
• Local time follows the selected offset and ignores daylight saving, so European and American summer months need a manual hour adjustment
• Display is at second precision while the millisecond value appears in its own column, which is where sub-second comparison belongs
• Everything runs in the browser and no value leaves the page; very long batches slow the table down, so paste in chunks
• The 1970 epoch itself converts to 1970-01-01 08:00:00 in UTC+8, which is the expected result rather than an error
• Values before 1970 keep their negative sign, and every converted row shows both the second and the millisecond figure so a value can be copied in either unit without re-running the tool; unparsable lines are reported instead of silently dropped.
• A batch may mix a bare timestamp and a written date on adjacent lines, because each line is interpreted on its own rather than against the first line format.