LogoTools
Runs entirely in your browser - nothing is uploaded

A Unix timestamp is the number of seconds (or milliseconds) since January 1, 1970 UTC: unambiguous for a machine, unreadable for a person. This converts a timestamp into a readable date in both your local timezone and UTC, and back the other way, auto-detecting whether a pasted number is in seconds or milliseconds.

When you'd use this

Reading a timestamp out of an API response, a log file, or a database row without doing the arithmetic in your head. Or the reverse trip, turning a specific date and time into the epoch value a script or API expects.

Common errors

A date that's off by exactly one time zone's offset, often by several hours, usually means the local-time and UTC readings of the input got crossed. Check which one the original source used.

A timestamp landing decades away in either direction almost always means seconds and milliseconds got confused. 1700000000 is a valid date in seconds (late 2023), and an implausibly early one if read as milliseconds.

Frequently asked questions

How does this tell seconds and milliseconds apart automatically?

By digit count. A seconds-based Unix timestamp for any date in the last ~50 years has 10 digits, while the same moment expressed in milliseconds has 13. That gap is wide enough to detect reliably without you having to say which unit you're pasting.

Why does the same timestamp show two different times?

One is your local time, taken from your device's timezone setting, and the other is UTC. Same instant, displayed two ways. APIs and logs commonly store UTC to sidestep timezone ambiguity, so both readings are shown here.

Learn More

Designing around third-party rate limits before they design around youIf your integration only handles a rate limit when it gets a 429, the limit is running your architecture. Treating it as a known constraint from the start changes how you queue, schedule, and prioritise work.Webhooks you can trust: idempotency, ordering, and the retries you didn't plan forA webhook endpoint that assumes each event arrives once, in order, and only once is an endpoint that corrupts data on the first busy day. Here's what a receiver actually has to handle.Scaling a Game Top-Up Platform to ₹1.5 Cr: Multi-gateway payments and automationBuilding a high-volume digital e-commerce store requires robust multi-gateway failovers and automated provider integrations. Here is how we scaled a digital game recharge platform.The API that returned 200 OK and lost our data anywayA supplier API answered every request with HTTP 200. During throttling, the body came back empty. Status codes alone told us everything was fine while records quietly went missing.Building a Stock Screener: Aggregating and transforming multi-country financial data in PythonProcessing real-time stock and crypto markets data feeds requires robust aggregation pipelines. Here is how we engineered a stock compliance screening engine.Ingesting a seven-million-record catalog, twice a dayHow we structured a vendor feed of 7M+ products into a staged pipeline (ingest, enrich, categorise, distribute) so a full refresh and a four-hourly price sync could run without manual intervention.Making a long-running bulk job safe to restartDownloading hundreds of thousands of files takes hours, and something always interrupts it. Here's the small amount of bookkeeping that turns a restart from a disaster into a non-event.