Unix epoch timestamps: a practical conversion guide

Know what a Unix timestamp represents

A Unix timestamp represents an instant as an amount of time from 00:00:00 UTC on 1 January 1970, commonly called the Unix epoch. A timestamp is useful because systems can exchange one number without first agreeing on a written date format. The same instant can later be displayed in UTC, India Standard Time or another local time zone.

The most common unit is seconds. Many browser and JavaScript interfaces use milliseconds, which makes the number roughly one thousand times larger. Modern epoch seconds usually contain ten digits, while epoch milliseconds usually contain thirteen. That size difference is a helpful clue, but a field name or API document is stronger evidence than automatic detection.

Unix time does not contain a time-zone name. The number identifies the instant; the presentation layer chooses a zone when it turns that instant into a readable date. If a log says an event occurred at a given epoch value, converting it to UTC and local time should describe the same moment with different clock readings.

Convert an epoch value into a readable date

Paste the numeric timestamp into the Epoch to date field. Choose seconds or milliseconds when the source tells you the unit. Automatic detection is convenient for ordinary current timestamps, but explicitly choosing the documented unit is safer for old dates, far-future values and unusual systems. Select Convert to date to see an ISO UTC value and the corresponding date formatted in your device's local zone.

The ISO result ends with Z, which means UTC. A local result depends on the operating system's time-zone setting and daylight-saving rules. When investigating an incident, record which form you used. UTC is normally best for comparing servers in different locations, while local time is useful for matching a user's report or a business schedule.

Use the current-time button to create a known example in all input areas. This is a quick way to confirm the unit expected by another application: compare the sample with its displayed time. If a converted date appears around January 1970 or thousands of years away, seconds and milliseconds were probably confused.

Convert a local date and time into epoch

Choose a date and time in the Date to epoch panel. A browser datetime-local field intentionally has no written time-zone suffix, so the converter interprets it using the current device's local time zone. It returns both whole epoch seconds and epoch milliseconds. Copy the unit required by the target system instead of assuming all APIs use the same one.

If the intended time was UTC rather than local time, adjust the entry or verify the result by converting it back and checking the ISO line. Developers should prefer an input format that includes an explicit offset, such as 2026-10-21T12:00:00+05:30, when an API supports it. A bare date and clock time becomes ambiguous when moved between devices in different zones.

Daylight-saving transitions can make a local clock time occur twice or not occur at all in some regions. India does not currently use daylight saving, but logs and customers may come from places that do. For scheduling across zones, preserve an IANA time-zone name such as Europe/London in the application data; an epoch value alone preserves the instant but not the user's original scheduling rule.

Troubleshoot timestamps in APIs, logs and databases

Start by finding the field definition. Names ending in At, timestamp, epoch, created or expires do not guarantee a unit. Check sample values and compare their digit length. Convert one known record, such as a login you just performed, and confirm that it matches the expected time. Never rewrite stored values in bulk based only on a visual guess.

A value that is consistently five hours and thirty minutes away from the expected Indian time is probably being displayed as UTC rather than IST, or being interpreted twice. A value that is about one thousand times too large or small indicates a seconds-versus-milliseconds error. A date one day away can come from formatting a UTC midnight in a local zone on the previous or following date.

The SableApps converter runs locally and is suitable for individual diagnostic values. It does not import log files, account for leap seconds, change a database, or prove when an event actually occurred. Treat timestamps from untrusted tokens and client devices as claims until the responsible server or signed record confirms them.

Quick checklist

• Confirm whether the source uses seconds or milliseconds.
• Use UTC when comparing systems in different locations.
• Record the local time zone when discussing a displayed date.
• Round-trip a known value before converting production data.
• Investigate large offsets before changing stored timestamps.