Timestamp Conversion Guide: Unix Time, Dates and Time Zones

Why Timestamps Confuse Everyone

You copy a number like 1695024000 out of a database or an API response, and it means nothing at a glance. Timestamp conversion turns that raw value into a readable date, and it also turns a readable date back into a number a system will accept. This guide covers Unix time, date formats and time zones, and it shows you how to convert between them without guessing.

The confusion is not your fault. Four different systems store the same moment in four different ways, and none of them labels the format clearly. Once you know which format you are looking at, the conversion is mechanical.

What Is a Unix Timestamp?

A Unix timestamp is the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970. That starting point is called the Unix epoch. A timestamp of 0 means the epoch itself, and a timestamp of 86400 means exactly one day later, because there are 86,400 seconds in a day.

The format is popular because it is compact, unambiguous and easy to sort. A single integer compares correctly with a simple greater-than check, which is why databases and log files store time this way.

Two details trip people up:

• Seconds versus milliseconds. Some systems store ten digits, others store thirteen. A thirteen-digit value is almost always milliseconds, so divide by 1,000 before converting.
• No time zone inside the number. A Unix timestamp always refers to UTC. Time zone information lives outside the value, in how you choose to display it.

A Unix timestamp is a point in time, not a calendar date. The calendar date only appears once you pick a time zone.

Seconds, Milliseconds and the Epoch

If a value has ten digits, treat it as seconds. If it has thirteen, treat it as milliseconds. If it has sixteen or more, it is probably microseconds or nanoseconds, which appear in high-precision logging. Converting the wrong unit shifts your result by decades, so check the digit count before you trust the output.

Dates before 1970 produce negative timestamps. This is valid and well defined, but some tools reject negative input, so verify the result if you work with historical records.

How to Convert a Timestamp Step by Step

This sequence works whether you are reading a value by hand or building a small script.

1. Count the digits. Ten digits means seconds. Thirteen means milliseconds. Note the unit before anything else.
2. Normalise to seconds. If the value is in milliseconds, divide by 1,000 and keep the remainder in mind if you need sub-second precision.
3. Decide the target time zone. UTC is the safe default for logs and databases. Use a local zone only when a human will read the result.
4. Convert and read the result. Paste the value into a timestamp converter and confirm the year looks plausible before you copy anything.
5. Check daylight saving. If the output falls near a clock change, verify the offset for that specific date rather than assuming a fixed one.
6. Reverse the conversion to test it. Convert the readable date back to a timestamp. If you get the original number, your settings are correct.

Step six catches most mistakes. A wrong time zone or a wrong unit usually survives a single conversion but fails a round trip.

How Do You Convert a Date to a Unix Timestamp?

To convert a date to a Unix timestamp, take the date and time in UTC, work out how many seconds separate it from 1 January 1970, and drop the fractional part. For a date such as 15 March 2024 at 12:00 UTC, the result is a ten-digit integer. Most programming languages and spreadsheet functions do this in one call, and browser-based converters do it instantly.

The one thing to get right is the input zone. If you type a local time but the tool assumes UTC, the result will be off by your offset. Set the zone explicitly before you convert.

Choosing Between 12-Hour and 24-Hour Input

Both formats convert correctly, but 24-hour input removes ambiguity. In a 12-hour format, 12:30 could mean half past midnight or half past noon depending on the convention in use. If you are pasting values from a log file, they are almost always in 24-hour form.

Converting Unix Time to a Human-Readable Date

Going the other direction is the more common task. You have a number, and you want a date a person can read.

The conversion is straightforward once the zone is fixed. Add the offset to UTC, then format the result as year, month, day, hour, minute and second. Two decisions change the output:

• Format. ISO 8601 (2024-03-15T12:00:00Z) sorts correctly as text and is the best choice for data interchange. A format like 15 March 2024, 12:00 reads better in a user interface.
• Zone label. Always state the zone. 12:00 UTC and 12:00 EST are different moments, and an unlabelled time is a bug waiting to happen.

Reading Timestamps in Log Files

Server logs usually store UTC and display it without a suffix. When you convert those values, keep the output in UTC so it lines up with neighbouring entries. Switching to a local zone mid-investigation makes a sequence of events look out of order.

Handling Time Zones During Timestamp Conversion

Time zones are where most conversion errors start. A time zone is a region's agreed offset from UTC, and that offset can change twice a year in places that observe daylight saving.

Three rules keep you out of trouble:

1. Store in UTC. Convert to a local zone only at the moment of display.
2. Never store a local time without its zone. A bare 09:00 is not a moment in time.
3. Treat offsets as data, not constants. An offset that was correct in January may be wrong in July.

Offsets are written as UTC+05:30 or UTC-08:00. The half-hour and quarter-hour offsets are real and used in several regions, so do not assume offsets are always whole hours.

UTC, GMT and Offset Notation

UTC is the modern time standard. GMT is a time zone that shares the same offset but carries a different name and history. For conversion purposes they produce identical results, but UTC is the correct label for stored data. When you see a trailing Z on a timestamp, such as 2024-03-15T12:00:00Z, the Z means UTC.

Daylight Saving and the Missing Hour

During a spring-forward transition, one hour of local time does not exist. During autumn, one hour occurs twice. This means a local time alone cannot always identify a unique moment. If you convert a local time that falls in the skipped hour, the result is undefined or silently shifted, depending on the tool. Converting from UTC avoids the problem entirely, because every UTC moment is unique.

Common Timestamp Formats You Will Meet

Different systems favour different layouts. Recognising them speeds up the conversion.

• Unix seconds: 1710504000
• Unix milliseconds: 1710504000000
• ISO 8601: 2024-03-15T12:00:00Z
• RFC 2822: Fri, 15 Mar 2024 12:00:00 +0000
• Compact local: 20240315T120000

The first two are numbers and need a unit check. The last three are text and carry their own zone information, which makes them safer to store but bulkier.

Which Timestamp Format Should You Store?

Store UTC, and choose a format based on what the value has to do. Use Unix seconds for compact storage and fast sorting. Use ISO 8601 when a human or another system will read the value directly. Avoid storing local times, and if you must, store the offset alongside them in a separate field.

For most applications, a single rule covers everything: keep UTC in the database, convert at the edge, and label the zone every time the value leaves your system.

FAQ

What is the difference between a Unix timestamp and a date?

A Unix timestamp is a single number counting seconds from a fixed starting point in UTC. A date is a calendar label made of a year, month and day, and it only makes sense alongside a time zone. The timestamp identifies a moment; the date describes how that moment looks in a particular place.

Why does my converted timestamp show the wrong year?

The most common cause is a unit mismatch. A thirteen-digit value is in milliseconds, and converting it as seconds pushes the result thousands of years into the future. Count the digits first, then divide by 1,000 if needed.

Do timestamps change with daylight saving?

No. A Unix timestamp is fixed in UTC, so it never shifts. What changes is the local offset applied when you display it. Two conversions of the same timestamp can show different clock times in a daylight-saving region, and both are correct.

Can a timestamp be negative?

Yes. Values before 1 January 1970 are negative, and they are valid. Some libraries and tools handle them poorly, so test the result if your data includes older records.

Is Unix time the same as UTC?

They are related but not identical. UTC is a time standard. Unix time is a counting convention measured from the epoch in UTC. Unix time inherits its reference point from UTC, which is why the two are often mentioned together.

Getting Timestamp Conversion Right

Once you know the unit, the epoch and the target zone, timestamp conversion stops being guesswork. Keep your stored values in UTC, convert at the point of display, and round-trip the result to confirm it. A browser-based converter handles the arithmetic instantly, and you can find one among the other utilities in the toolbox when you need a quick check. Get the zone right and everything else follows.