How to Convert a Timestamp to a Readable Date

October 17, 2026 • NOFYI Editorial Team

A timestamp is a number that represents a moment in time. It is compact, easy to store, and easy to compare. It is also hard for a person to read. The number 1700000000 does not look like a date, yet it represents a specific day and time. Converting a timestamp to a readable date turns that number into something a reader can understand.

This guide explains how to convert a timestamp to a readable date. It covers the difference between seconds and milliseconds, the steps to follow, and a worked example you can check. It also explains time zones, common mistakes, and the limits of a simple conversion.

What a Timestamp Is

A Unix timestamp, also called Epoch time, counts the number of seconds that have passed since 1 January 1970 at 00:00:00 UTC. That starting point is called the Epoch. A timestamp is therefore a count, not a formatted date. The same moment can be written as a timestamp, as a date and time, or as a date in a different time zone.

Timestamps are widely used in logs, databases, APIs, and file metadata. They are useful because they are simple numbers. They can be sorted, compared, and stored without worrying about date formats. The trade-off is that they are not readable without conversion.

Some systems use seconds, and some use milliseconds. A timestamp in seconds has ten digits for current dates. A timestamp in milliseconds has thirteen digits, because it includes thousandths of a second. That difference is the most common source of conversion errors, so it deserves careful attention.

How to Convert a Timestamp to a Readable Date

Use the following steps for any timestamp. They work whether you are using a converter tool, a spreadsheet, or code.

Step 1: Identify the Unit

Look at the number of digits. A ten-digit number for a current date is usually seconds. A thirteen-digit number is usually milliseconds. A sixteen-digit number is usually microseconds. If you are unsure, check the source. Documentation, a field name, or an example in the same system can tell you the unit.

Do not guess the unit from the number alone when the stakes are high. A ten-digit number and a thirteen-digit number can both look plausible, but they represent very different moments if they are interpreted in the wrong unit. Confirm the unit before you convert.

Step 2: Convert Milliseconds to Seconds When Needed

If the timestamp is in milliseconds, divide it by 1,000 to get seconds. For example, 1700000000000 milliseconds divided by 1,000 is 1700000000 seconds. Many converters and programming functions expect seconds, so this step prevents a date far in the future.

If the timestamp is already in seconds, do not divide it. Dividing a seconds timestamp by 1,000 would produce a date in 1970, which is clearly wrong for a current event. The unit check in Step 1 protects you from that mistake.

Step 3: Convert the Seconds Value to a Date and Time

Use a converter, a date function, or a programming language to turn the seconds value into a date and time. Most tools have a function that takes a timestamp and returns a date. In a spreadsheet, you may need to add the timestamp, divided by 86,400, to the Epoch date. In code, you can use a date library that handles the conversion.

When you convert, choose whether you want the result in UTC or in a local time zone. UTC is a good default for sharing, logging, and comparison, because it does not change with daylight saving time or with the reader location. A local time is useful when the reader needs to know when something happened in their own time zone.

Step 4: Check the Time Zone

A timestamp itself does not have a time zone. It represents an absolute moment. The readable date depends on the time zone you use to display it. The same timestamp can be 14 November in one time zone and 15 November in another, if the time is close to midnight.

Always state the time zone when you share a converted date. Write UTC after a UTC time, or name the local time zone. If you convert a timestamp for an event, a deadline, or a log entry, a missing time zone can cause a missed meeting or a wrong conclusion. A clear time zone label removes that ambiguity.

Step 5: Format the Result for Readers

Choose a format that is clear and unambiguous. A format such as 14 Nov 2023 22:13:20 UTC is easy to read, because the month is written as a word and the time zone is stated. A format such as 11/14/2023 can be ambiguous, because some readers read it as day first and others read it as month first.

Include the year, the month, the day, and the time when the exact moment matters. If only the date matters, you can omit the time, but still state the time zone if the date could change across zones. Consistency helps readers, so use the same format throughout a document or a report.

Step 6: Verify the Result

Check the converted date against a known reference. If the timestamp came from an event you know, confirm that the converted date matches that event. If the timestamp came from a log, confirm that the date falls in the expected range. If the result looks far in the past or far in the future, recheck the unit and the time zone.

A simple sanity check is to compare the converted date with the current date. A timestamp for a recent event should convert to a recent date. A timestamp for an old file should convert to an older date. If the result does not make sense, the unit is the most likely cause.

Worked Example

Suppose you have the timestamp 1700000000. First, identify the unit. It has ten digits, so it is in seconds. Next, convert it to a date and time in UTC. The result is 14 Nov 2023 22:13:20 UTC.

To check the unit, consider what would happen if you treated the same number as milliseconds. Dividing by 1,000 would give 1700000 seconds, which converts to a date in January 1970. That result is clearly wrong for a timestamp that is meant to represent a recent event. The ten-digit check confirms that seconds is the correct unit.

Now consider the millisecond version of the same moment: 1700000000000. It has thirteen digits, so it is in milliseconds. Divide by 1,000 to get 1700000000 seconds. Convert that value in UTC, and you get the same result: 14 Nov 2023 22:13:20 UTC. The two timestamps represent the same moment, in different units.

Finally, consider the time zone. The UTC result is 14 Nov 2023 22:13:20 UTC. In a time zone that is five and a half hours ahead of UTC, such as Asia/Kolkata, the same moment is 15 Nov 2023 03:43:20 local time. The date changes because the local time is past midnight. That is why stating the time zone matters. Without it, a reader could report the wrong date.

Seconds Versus Milliseconds

Seconds and milliseconds are the two units you will meet most often. Seconds are common in Unix timestamps, in many databases, and in older systems. Milliseconds are common in JavaScript, in many APIs, and in systems that need finer precision. Some systems use microseconds or nanoseconds, but those are less common in everyday work.

A quick way to tell the units apart is to count the digits. Ten digits means seconds for current dates. Thirteen digits means milliseconds. If the number has a different length, check the source. A timestamp with a decimal point may include a fractional part, which can also affect the unit.

Do not confuse milliseconds with seconds when you write code. A function that expects seconds will return a date far in the future if you give it milliseconds. A function that expects milliseconds will return a date in 1970 if you give it seconds. The error is often obvious, because the date is wildly wrong, but it can still cause confusion if it is not caught.

Time Zones and Daylight Saving Time

Time zones are offsets from UTC. Some time zones are a whole number of hours ahead or behind UTC. Others, such as India Standard Time, are offset by hours and minutes. Daylight saving time can change the offset for part of the year. A converter that uses a named time zone, such as Asia/Kolkata or America/New_York, can handle those changes. A fixed offset, such as UTC+5:30, cannot handle daylight saving time on its own.

When you convert a timestamp, use a named time zone when possible. It is more accurate than a fixed offset for dates in the past or future. If you only have a fixed offset, state it clearly, and note that it may not account for daylight saving time.

For logs and for data that will be shared across regions, UTC is often the safest choice. It avoids the complexity of local time zones and daylight saving time. A reader can then convert the UTC time to their own local time when they need to.

Common Mistakes

One common mistake is confusing milliseconds and seconds. Another is forgetting the time zone. A third is using an ambiguous date format. A fourth is assuming that a timestamp is in local time when it is actually in UTC, or the other way around.

Another mistake is treating a timestamp as a date without checking the source. A number that looks like a timestamp could be an identifier, a duration, or a value in a different unit. Check the field name, the documentation, or a known example before you convert.

A final mistake is rounding or truncating a timestamp without thinking. Dropping the last three digits of a millisecond timestamp is correct when you want seconds. Dropping digits from a seconds timestamp changes the date. Keep the full value until you have confirmed the unit.

Limitations

Converting a timestamp has limits. A conversion cannot tell you whether the timestamp itself is correct. If the source recorded the wrong time, the converted date will also be wrong. A conversion also cannot tell you the time zone that the original system used, unless that information is recorded separately.

A conversion cannot handle every historical change perfectly. Time zone rules have changed over time, and some historical dates may be converted differently by different tools. For most everyday work, that does not matter, but for historical research it can.

A timestamp also has a limited range. Very old or very far-future dates may not be supported by every tool. If you are working with dates far outside the usual range, check that your tool supports them.

Finally, a readable date is not always the best way to share a moment. For sorting, for storage, and for comparison, the timestamp itself is often better. Use the readable date for people, and keep the timestamp for systems.

Frequently Asked Questions

How do I know if a timestamp is in seconds or milliseconds?

Count the digits. A ten-digit timestamp for a current date is usually seconds. A thirteen-digit timestamp is usually milliseconds. If you are unsure, check the source, and test the conversion. A wrong unit usually produces a date that is clearly far in the past or far in the future.

What does 1700000000 convert to?

The timestamp 1700000000, in seconds, converts to 14 Nov 2023 22:13:20 UTC. The millisecond version, 1700000000000, converts to the same moment. Always state the time zone when you share the result.

Why does the same timestamp show a different date in another time zone?

A timestamp represents an absolute moment. The readable date depends on the time zone used to display it. Near midnight, the same moment can fall on different dates in different zones. State the time zone to avoid confusion.

Should I store dates as timestamps or as readable dates?

Store the timestamp for sorting, comparison, and storage, because it is unambiguous. Show a readable date, with a stated time zone, when people need to read it. Keep both when you need both kinds of use.

Conclusion

Converting a timestamp to a readable date is a short process when you follow the steps. Identify the unit, convert milliseconds to seconds when needed, convert the value to a date and time, check the time zone, format the result clearly, and verify it. Do not confuse milliseconds with seconds, and do not share a converted date without stating the time zone. That routine will turn a long number into a date that readers can trust.