What Is a Unix Timestamp and How Do You Read One

October 17, 2026 • NOFYI Editorial Team

What Is a Unix Timestamp?

A Unix timestamp is a way of representing a single moment in time as one number. Instead of writing a date and time in the familiar form of day, month, year, hours, minutes, and seconds, a Unix timestamp counts the number of seconds that have passed since a fixed starting point. That starting point is 1 January 1970 at 00:00:00 UTC, a moment often called the Unix epoch. So when you see a number such as 1700000000, you are looking at a count of seconds since that epoch. The larger the number, the later the moment it describes. This system is used widely in computing because a single number is easy to store, compare, sort, and pass between programs, databases, and services without worrying about different date formats, punctuation, or language conventions.

If you have ever inspected a website, worked with an application programming interface, exported data from a database, or looked at a log file, you may have seen a long ten-digit number where you expected a readable date. That number was probably a Unix timestamp. It looks unfriendly at first, but once you understand the idea behind it, it becomes a compact and reliable way to describe time. The key idea is simple: pick one universal reference moment, then count seconds forward from it. Every second gets its own unique number, and every number points back to exactly one second.

Why Computers Use a Single Number for Time

Human date formats are convenient for people but awkward for computers. Different countries write dates in different orders, use different separators, and use different names for months. Some formats use twelve-hour clocks with AM and PM, while others use twenty-four-hour clocks. Time zones add another layer of confusion. A single number avoids most of that confusion. A Unix timestamp has no month names, no separators, and no AM or PM. It is just an integer, which means it can be stored efficiently, compared with simple arithmetic, and sorted without parsing text.

For example, finding out which of two events happened first is straightforward when both are timestamps. You compare the two numbers. The smaller number happened earlier, and the larger number happened later. Calculating the gap between them is subtraction. If one event has timestamp 1700000000 and another has timestamp 1700003600, the difference is 3600 seconds, which is exactly one hour. Doing the same calculation with formatted date strings would require parsing both strings, handling time zones, and accounting for days, months, and years. The number form keeps the arithmetic simple and consistent, which is why so many systems store time this way internally, even when they show a friendly date to the user.

Timestamps are also useful when data moves between systems. A database in one country, a server in another, and a browser on a phone can all agree on what 1700000000 means, because the definition does not depend on local conventions. The display can be adjusted for the viewer, but the stored value stays the same. That separation between storage and display is one of the main reasons Unix timestamps remain common in web development, logging, analytics, scheduling, caching, and many other areas.

How to Read a Unix Timestamp

Reading a Unix timestamp means converting that count of seconds back into a calendar date and clock time. You do not need to do this by hand in most cases. The practical approach is to use a converter tool, a programming language function, or a spreadsheet formula, and then check the result against the context you expect. Still, it helps to understand what the steps are, so you can spot mistakes such as mixing up seconds and milliseconds or forgetting about time zones.

Step 1: Check Whether the Number Is in Seconds or Milliseconds

Look at the length of the number first. A current Unix timestamp in seconds has ten digits. A current timestamp in milliseconds has thirteen digits, because it counts thousandths of a second rather than whole seconds. This is the most common source of confusion. If you feed a thirteen-digit millisecond value into a tool that expects seconds, you will get a date thousands of years in the future. If you feed a ten-digit second value into a tool that expects milliseconds, you will get a date in January 1970. When in doubt, check the source or the documentation for the system that produced the number.

Step 2: Convert the Count to a Date and Time in UTC

Convert the seconds to a date and time using UTC as the reference time zone. UTC is the baseline used by the definition of the Unix timestamp. Starting from 1 January 1970 at 00:00:00 UTC, add the number of seconds. A converter or a date function does this calculation for you. The result is the moment in UTC, which is the version you should use when comparing values or sharing them with other systems.

Step 3: Adjust to a Local Time Zone Only for Display

Once you have the UTC moment, you can shift it to a local time zone if you need to show it to a person. For example, a moment that is 22:13:20 in UTC might be a different clock time in London, New York, or Kolkata, depending on the offset and whether daylight saving time applies. The underlying moment is the same. Only the label changes. Keep the timestamp itself in UTC in storage, and apply the time zone shift at the moment you display the value.

Step 4: Check the Result Against What You Expect

Finally, sanity-check the converted date. Does it fall in the period you expect? Does it make sense alongside nearby events? If a log entry claims to be from last week but converts to a date in 2001 or 2055, something is wrong. The usual suspects are seconds versus milliseconds, a missing or extra digit, or a tool that assumed a different time zone. A quick check at this stage saves a lot of confusion later.

Worked Example: Reading 1700000000

Let us work through the example number from the title in full. The timestamp is 1700000000. It has ten digits, so it is a count in seconds, not milliseconds. That means it represents 1,700,000,000 seconds after 1 January 1970 at 00:00:00 UTC.

Converting that count gives 14 November 2023 at 22:13:20 UTC. You can break that result down to make it easier to trust. The date is 14 November 2023. The clock time in UTC is 22:13:20, which is 10:13:20 PM in twelve-hour notation. If you were showing this moment to someone in India, where the standard offset is UTC plus five hours and thirty minutes, the local display would be 15 November 2023 at 03:43:20 IST. If you were showing it to someone in New York during standard time, where the offset is UTC minus five hours, the local display would be 14 November 2023 at 17:13:20 EST. All of those labels describe the same instant. The timestamp itself does not change.

You can also verify the arithmetic in reverse. If you take 14 November 2023 at 22:13:20 UTC and count the seconds back to the epoch, you return to 1700000000. Most converter tools let you check both directions, and that round-trip check is a useful way to confirm that a value has not been mistyped. In practice, you would not do this calculation by hand. You would paste the number into a converter, use a date function in your programming language, or use a command-line tool. The important part is knowing what the number means and which time zone the result is expressed in.

This example also shows why timestamps are useful for comparing moments. Suppose a second event has timestamp 1700003600. Subtracting gives 3600 seconds, which is one hour. So the second event happened exactly one hour after the first. You do not need to work through days, months, or time zone offsets to reach that answer. The numbers give it to you directly.

Milliseconds Versus Seconds

Many modern systems need finer precision than whole seconds, so they use milliseconds. One second contains one thousand milliseconds. A timestamp in milliseconds for the same moment as 1700000000 seconds would be 1700000000000, which has thirteen digits. JavaScript, for example, commonly works with milliseconds when it creates date values. Some databases and logging systems also store milliseconds so they can order events that happen within the same second.

The rule is simple: if the number has thirteen digits and describes a recent date, it is probably milliseconds. Divide by one thousand to get seconds, or use a converter that has a milliseconds option. If the number has ten digits and describes a recent date, it is probably seconds. Do not trim or pad digits by guessing. Check the documentation for the system that produced the value, and be consistent within a single project. Mixing seconds and milliseconds in the same column or field is a common bug, and it produces dates that are wildly wrong in a way that is usually easy to spot once you know what to look for.

Some systems also use microseconds or nanoseconds, which add even more digits. Those are less common in everyday web work, but the same principle applies. Count the digits, check the unit, and convert to seconds before you compare values from different sources. When you store timestamps, record the unit alongside the field name or in the documentation, so the next person working with the data does not have to guess.

Time Zones and Unix Timestamps

A Unix timestamp itself has no time zone. It describes a single instant, and that instant is defined relative to UTC. Time zones only enter the picture when you convert the timestamp into a readable date and time for display. This is an important distinction. Two people in different time zones who look at the same timestamp are looking at the same moment, even though their clocks show different times. The difference is in the label, not in the event.

This property makes timestamps useful for scheduling, logging, and analytics. A server can record events in UTC, and each viewer can see those events in their own local time without changing the stored data. It also avoids a whole class of errors that come from storing local times without recording which time zone they belong to. If you store a local time without a time zone, you cannot reliably compare it with times from other zones, especially around daylight saving transitions when clocks move forward or backward. Storing the timestamp keeps the underlying moment unambiguous.

When you display a timestamp, state the time zone you are using. A label such as 14 November 2023, 22:13:20 UTC is clear. A label such as 14 November 2023, 22:13:20 without a time zone leaves the reader guessing. If your audience is in one specific region, you can show the local time and name the zone, for example IST or EST. If your audience is spread across regions, showing UTC and letting the viewer convert is often the clearest choice.

Common Mistakes to Avoid

The most frequent mistake is treating milliseconds as seconds, or the reverse. The second most frequent mistake is forgetting that the displayed time depends on the time zone. A converter that defaults to your browser time zone will show a different clock time from a converter that defaults to UTC, even though both are describing the same timestamp. A third mistake is assuming that a timestamp includes information about the calendar, such as the day of the week or the month name. It does not. Those are derived when you convert the number. Finally, avoid storing formatted date strings when you need to sort, filter, or calculate durations. Store the timestamp, and format it only when you display it.

Limitations of Unix Timestamps

Unix timestamps are practical, but they are not perfect. They are hard for people to read without a converter, so they are a poor choice for anything a person must read directly, such as a printed letter or a sign. They also have a limited range when stored as a 32-bit signed integer. On systems that still use that format, the count runs out in January 2038, a problem sometimes called the Year 2038 problem. Modern systems that use 64-bit integers have a far larger range, but older software and file formats may still be affected, so it is worth knowing that the limit exists.

Another limitation is precision. A timestamp in whole seconds cannot distinguish between two events that happen within the same second. If your application needs to order events more finely, you need milliseconds or a finer unit. Timestamps also do not capture calendar details such as time zone rules, daylight saving history, or leap seconds in a way that is visible from the number alone. Leap seconds, which are occasional adjustments to UTC, are handled differently by different systems, and that can create small inconsistencies at the edges. For most everyday uses, these limitations do not matter, but they are worth keeping in mind when you need exact ordering or long-term archival.

Timestamps also depend on clocks being correct. If a device clock is wrong, the timestamps it records will be wrong too. That is not a flaw in the timestamp idea itself, but it is a practical reminder to use reliable time sources and to check for clock drift in systems where accurate ordering matters.

Frequently Asked Questions

What is the Unix epoch?

The Unix epoch is 1 January 1970 at 00:00:00 UTC. It is the reference moment from which Unix timestamps count seconds. It was chosen for historical reasons in the early development of Unix systems, and it has remained the standard reference point ever since.

How do I convert a Unix timestamp to a date?

Paste the number into a Unix timestamp converter, or use a date function in your programming language. Check first whether the number is in seconds or milliseconds, then convert to UTC, and adjust to a local time zone only for display. Always sanity-check the result against the period you expect.

Is a Unix timestamp always in UTC?

The timestamp itself describes a moment defined relative to UTC. It does not carry a separate time zone. When you convert it for display, you choose which time zone to show. The underlying moment stays the same regardless of the display zone.

Why does my timestamp show the wrong date?

The usual causes are mixing up seconds and milliseconds, using a converter that assumes a different time zone from the one you expected, or a mistyped digit. Check the number of digits first, then check the time zone setting, then verify the number against the original source.

Conclusion

A Unix timestamp is a count of seconds since 1 January 1970 at 00:00:00 UTC. It is compact, easy to compare, and independent of local date formats, which is why so many systems use it for storage and exchange. To read one, check whether it is in seconds or milliseconds, convert it to a date and time in UTC, and only then adjust it for display in a local time zone. With that approach, a number such as 1700000000 becomes a clear moment: 14 November 2023 at 22:13:20 UTC. Once you are comfortable with that process, timestamps stop looking like random numbers and start looking like what they are: a simple, consistent way to describe time.