Enter the required information
Use the fields in the tool above and keep units and formats consistent.
Convert Unix epoch seconds or milliseconds into readable UTC and IST dates, or turn a date back into a timestamp. Handy for logs, APIs and database rows.
A log file says an error happened at 1700000000. That number is a Unix timestamp, the count of seconds since 00:00:00 UTC on 1 January 1970. Converted, it reads 14 November 2023, 22:13:20 UTC. In India the same moment is 15 November 2023, 03:43:20 IST. A timestamp converter does this translation in both directions, epoch to date and date to epoch.
Unix time has no time zone of its own and skips leap seconds. One number means the same instant everywhere on earth. Only the local clock reading changes. India keeps no daylight saving time, so IST is always UTC plus 5 hours 30 minutes.
Systems store epoch time at different precision. For present-day dates, digit count is the quickest way to tell which unit you are holding.
| Digits | Unit | Typical source |
|---|---|---|
| 10 | Seconds | Linux shell, PHP time(), MySQL UNIX_TIMESTAMP() |
| 13 | Milliseconds | JavaScript Date.now(), Java System.currentTimeMillis() |
| 16 | Microseconds | GA4 BigQuery exports, some database columns |
| 19 | Nanoseconds | Go UnixNano(), Python time.time_ns() |
A converted date in January 1970 usually means seconds were read as milliseconds. A date tens of thousands of years ahead means the opposite mistake. Multiply or divide by 1,000 and convert again.
Math.floor(Date.now() / 1000) for now, and new Date(ts * 1000) to read one.int(time.time()), then datetime.fromtimestamp(ts, ZoneInfo("Asia/Kolkata")) for IST.time() and date("Y-m-d H:i:s", $ts).SELECT UNIX_TIMESTAMP(); and FROM_UNIXTIME(ts).date +%s.=A1/86400 + DATE(1970,1,1) gives UTC from a value in A1.For IST in a spreadsheet, add + 5.5/24 to that formula. Then format the cell as date and time, or you will only see a serial number.
Most conversion bugs come from mixing UTC with local time. Servers in Mumbai and Frankfurt store the same epoch value for the same event. Trouble starts when someone formats it without stating the zone. Store timestamps in UTC and convert to IST, or the viewer's zone, only at display time.
The 2038 problem affects systems storing Unix time as a signed 32-bit integer. Its largest value, 2147483647, lands at 03:14:07 UTC on 19 January 2038. One second later, those counters wrap round to a date in 1901. Modern 64-bit systems are safe, but old embedded devices and legacy databases may not be.
To compare two events, subtract one timestamp from the other. A gap of 3600 means exactly one hour, and 86400 means one day. That is often faster than converting both values to dates. It also avoids slips when logs come from servers in different zones.
Paste boundary values like these into the ToolsMate timestamp converter when debugging. It is a quick way to confirm what a stored number means.
Use the fields in the tool above and keep units and formats consistent.
Review the result shown in the output area.
Confirm that the result matches your situation before using it for a decision.
Unix seconds are converted to a JavaScript Date and rendered as ISO-8601.This describes the core logic used by the tool. Check any assumptions that may affect your result.
Use accurate inputs and keep units consistent.
Review the assumptions before using the result for a decision.
Compare important results with an independent or official source.
None, strictly speaking. A Unix timestamp counts seconds from 1 January 1970 in UTC, so it marks one global instant. A time zone only comes into play when you format it as a readable date, such as IST or GMT.
Convert the timestamp to UTC first, then add 5 hours 30 minutes. India does not observe daylight saving time, so the offset never changes. In code, use the Asia/Kolkata zone name rather than hard-coding the offset by hand.
Your value is probably in seconds but is being read as milliseconds. JavaScript's Date constructor expects milliseconds, so new Date(1700000000) lands on 20 January 1970. Multiply a seconds value by 1,000 before passing it in.
No. Unix time treats every day as exactly 86,400 seconds and ignores leap seconds. When one occurs, systems either repeat a second or smear the adjustment across several hours. For logging and scheduling work, the difference almost never matters.
Midnight UTC on 1 January 2026 is 1767225600. Midnight IST on that date happened five and a half hours earlier, giving 1767205800. Always confirm which midnight a system means before comparing two values from different sources.
Yes. Negative values represent moments before 1 January 1970. For instance, -86400 is 00:00 UTC on 31 December 1969. Most modern languages handle negative values fine, though some older databases and spreadsheet formulas reject them.
ISO 8601 is a text format such as 2025-03-15T10:30:00+05:30, readable by people and machines alike. It carries an explicit offset. Epoch time is a bare number with no formatting. Many APIs accept both, so converting between them is routine.
Explore other useful tools across the site.