Convert UNIX Time to UTC
Convert a Unix timestamp into a readable date and time in a selected time zone. Helpful for debugging APIs, logs, and database records.
Convert UNIX Time to UTC
What this tool does
It turns a Unix timestamp, one of those long numbers you find in logs, API responses, and database rows, into a date and time you can actually read. You paste in the number, choose a time zone, and it shows you the moment it represents. To save you a step, it fills in the current timestamp automatically, so you can see what right now looks like as an epoch value.
How to use it
- Unix Timestamp. The number to decode. It starts on the current timestamp, so replace it with yours.
- Time Zone. The zone to show the result in. Pick UTC for the neutral view, or your own zone to see local time.
Press Calculate and the readable date and time appear.
What a Unix timestamp is
A Unix timestamp, also called epoch or POSIX time, is simply a count of seconds. It is the number of seconds that have passed since one fixed reference moment: midnight UTC on the 1st of January 1970, known as the epoch. So a timestamp of 0 is that exact instant, and a timestamp of 1700000000 is roughly 1.7 billion seconds later. Computers like it because a single growing number is easy to store, easy to sort, and easy to do sums with, since comparing two moments is just comparing two numbers, and the gap between them is plain subtraction.
Seconds, not milliseconds
This is the trap that catches people most, so it is worth saying plainly. This tool works in seconds, which for the current era is a 10-digit number. A lot of systems, JavaScript especially, count in milliseconds instead, which is a thousand times bigger and runs to 13 digits. That millisecond value is too large for this tool to accept, so if your number has 13 digits, divide it by 1000, or drop the last three digits, to get the 10-digit seconds value this tool expects.
Why it asks for a time zone
Here is the thing that makes timestamps clean: the number itself has no time zone. It is the same single moment everywhere in the world. A time zone only comes into it when you want to display that moment as a wall-clock time, because the same instant is, say, early afternoon in London and late evening in Tokyo. So picking a zone here does not change the moment, only how it is written out. Choose UTC when you want the neutral reference that servers and logs use, which is the safest view when records come from machines in different regions, or choose your own zone to see when the event happened in local terms.
A note on the year 2038
One piece of background you may run into. Older systems stored the timestamp in a 32-bit signed integer, and that kind of number runs out of room on the 19th of January 2038, when it cannot count any higher. This is the well-known Year 2038 problem, the modern echo of the Year 2000 one. Newer systems use a 64-bit number that pushes the limit absurdly far into the future, so it is not something you generally have to worry about now, but it explains why very old software may choke on dates past 2038.
Where it comes in handy
Mostly debugging and development. Reading the timestamp on a log line to see when something actually happened, checking the dates in an API response, making sense of a database record that stores times as epoch values, or just confirming what a particular number works out to. Any time you are staring at a big number that you know is a time but cannot read, this turns it back into a date.
Questions people ask
What is a Unix timestamp?
It is the number of seconds since midnight UTC on 1 January 1970, the epoch. It represents a single moment in time as one integer, which makes it easy for computers to store and compare.
My 13-digit timestamp will not work. Why?
It is in milliseconds, not seconds. A 13-digit millisecond value is larger than this tool accepts, so divide it by 1000, or drop the last three digits, to get the 10-digit seconds value, then try again.
Does choosing a time zone change the moment?
No. The timestamp is the same instant everywhere. The time zone only changes how that instant is written as a date and time, not which moment it is.
Should I use UTC or my local zone?
Use UTC for the neutral reference that servers and logs share, which avoids confusion across regions. Use your local zone when you want to see when the event happened in your own time.
References
- The Open Group, POSIX.1 Base Specifications, Base Definitions, "Seconds Since the Epoch." https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html
Skanda Aryal is a full stack engineer focused on accessible web experiences, with personal interests in time zones, travel, hiking, and geography. His enjoys playing with utilities tied to movement, schedules, places, and time based coordination. At Eon Tools, he reviews geography, transportation, times now, and date and time tools.
Other Tools
- Convert H:M:S to Hours
- Convert H:M:S to Minutes
- Convert H:M:S to Seconds
- Convert Hours to H:M:S
- Convert Minutes to H:M:S
- Convert Seconds to H:M:S
- Convert Seconds to Human Time
- Convert UTC Time to UNIX
- Decimal to Time Converter
- Military Time Converter
- Time to Decimal Converter
- Timesheet Converter
- Timestamp Generator
- Unix Timestamp Converter