Time is weird. If you think human time is confusing (why does February only have 28 days unless it is a leap year?), wait until you see how computers handle it.
Computers do not care about Tuesday morning or daylight saving time. They do not care about the month of August. Instead, computers count time using a single, giant, constantly growing number: the Unix Timestamp (also called Epoch time).
If you are a developer, a system admin, or a data analyst, you see these numbers everywhere. You look at server logs, API payloads, or database records, and instead of a readable date, you find something like 1774896000.
In this guide, we are going to break down exactly what this number is, why computers love it, and how you can convert it into a date you can actually read.
What is a Unix timestamp anyway?
Let us start with the basics. A Unix timestamp is simply the total number of seconds that have ticked by since a specific moment in history. That starting line is called the Unix Epoch.
The Unix Epoch is defined as: January 1, 1970, at 00:00:00 Coordinated Universal Time (UTC)
Every second that passes, this counter goes up by one. As I write this, we are well past 1.7 billion seconds.
Here is what makes this system great: it is a simple integer.
For a computer, comparing two integers is extremely fast. If you want to know if event A happened before event B, you just check if its timestamp is smaller. You do not have to parse string patterns or adjust for time zones. It is clean, simple, and incredibly efficient for database indexes.
Why do computers count time from January 1, 1970?
Why 1970? Why not 1900, or the birth of Christ, or the year the earth was formed?
The answer is a mix of history and convenience. The creators of Unix (Ken Thompson and Dennis Ritchie) were working on the operating system in the late 1960s. They needed a simple way to represent system time.
At first, they set the system clock to count 60ths of a second, starting from January 1, 1970. Later, they realized that counting 60ths of a second would make the integer overflow too quickly, so they changed it to count whole seconds instead.
They picked January 1, 1970, because it was a round date close to when they were working, and it served as a convenient base point. Since Unix became the foundation for modern operating systems (including Linux, macOS, iOS, and Android), the Unix Epoch became the standard for the entire tech industry.
What was the Year 2038 problem and how will it break databases?
If you are a developer, you need to know about the Year 2038 problem (often written as Y2K38). It is the Unix equivalent of the Y2K bug, but unlike Y2K, this one is a real physical limit in how computers store numbers.
Historically, Unix systems stored the timestamp as a 32-bit signed integer. A 32-bit signed integer has a maximum value of 2,147,483,647.
Let us do some math. If you add 2,147,483,647 seconds to January 1, 1970, what date do you get?
You get: January 19, 2038, at 03:14:07 UTC
At that exact second, the integer will reach its absolute limit. In the very next second, the number will overflow. Because it is a signed integer, the binary bit for the sign will flip, and the number will wrap around to its maximum negative value: -2,147,483,648.
For a 32-bit system, that negative number represents: December 13, 1901, at 20:45:52 UTC
Suddenly, the computer will think it has traveled 137 years into the past! Systems will crash, databases will corrupt, and date calculations will completely break.
How are we fixing this? The industry is moving to 64-bit integers to store time. A 64-bit integer can store values up to 9,223,372,036,854,775,807.
With 64-bit timestamps, the clock won’t overflow for another 292 billion years. That is about twenty times longer than the age of the universe, so we should be safe for a while. However, if you are still running legacy 32-bit databases or operating systems, you need to upgrade them soon.
What is the difference between standard Unix time and JavaScript epoch timestamps?
Here is one of the most common gotchas for web developers.
- Standard Unix Time: Counted in seconds. It is a 10-digit integer (like
1774896000). This is what Python, PHP, Ruby, databases, and most backend APIs use. - JavaScript / Java Time: Counted in milliseconds. It is a 13-digit integer (like
1774896000000).
If you take a standard 10-digit Unix timestamp and pass it directly to a JavaScript Date constructor, you will get a date in January 1970. Why? Because JS thinks you are passing milliseconds. It translates 1.7 billion milliseconds to about 20 days past the 1970 epoch.
To fix this, you must always multiply standard Unix timestamps by 1000 before working with them in JavaScript.
How to convert Unix timestamps to dates in JavaScript?
JavaScript has a built-in Date object that handles time zones and formatting. Here is how you convert a 10-digit Unix timestamp to a human-readable string:
const unixTimestamp = 1774896000; // 10 digits (seconds)
// Convert to milliseconds (13 digits)
const dateObject = new Date(unixTimestamp * 1000);
// Print as a standard UTC string
console.log(dateObject.toUTCString());
// Output: Sat, 28 Mar 2026 18:40:00 GMT
// Print using the user local time zone
console.log(dateObject.toString());
// Print a formatted date (MM/DD/YYYY)
console.log(dateObject.toLocaleDateString());If you are using modern JavaScript, you can use Intl.DateTimeFormat to format the output nicely without heavy external packages:
const formatter = new Intl.DateTimeFormat('en-US', {
dateStyle: 'full',
timeStyle: 'long'
});
console.log(formatter.format(dateObject));
// Output: Saturday, March 28, 2026 at 6:40:00 PM GMT+1How do you parse and print epoch times in Python?
Python makes it very easy to work with dates using the datetime module. Here is how you convert a Unix timestamp to a readable date in Python:
from datetime import datetime
timestamp = 1774896000
# Convert timestamp to a datetime object (local timezone)
local_date = datetime.fromtimestamp(timestamp)
print("Local Date:", local_date.strftime('%Y-%m-%d %H:%M:%S'))
# Convert timestamp to a datetime object (UTC)
utc_date = datetime.utcfromtimestamp(timestamp)
print("UTC Date:", utc_date.strftime('%Y-%m-%d %H:%M:%S UTC'))Python also makes it easy to go in reverse. If you have a datetime object and want to get the Unix timestamp, you just call the .timestamp() method:
from datetime import datetime
# Get current time as timestamp
now_timestamp = datetime.now().timestamp()
print("Current Unix Timestamp:", int(now_timestamp))How to handle timestamp conversions in SQL?
When querying databases, you often need to convert raw epoch integers into readable columns. Here is how you do it in the major SQL engines:
PostgreSQL
PostgreSQL uses the to_timestamp() function. It returns a timestamp with timezone:
SELECT to_timestamp(1774896000);
/* Output: 2026-03-28 18:40:00+00 */To go from a date back to a timestamp:
SELECT EXTRACT(epoch FROM NOW());MySQL
MySQL uses FROM_UNIXTIME():
SELECT FROM_UNIXTIME(1774896000);
/* Output: 2026-03-28 18:40:00 */To go from a date back to a timestamp:
SELECT UNIX_TIMESTAMP(NOW());SQLite
SQLite does not have a dedicated timestamp type. It stores dates as text, real, or integers. To convert a timestamp to a readable date:
SELECT datetime(1774896000, 'unixepoch');
/* Output: 2026-03-28 18:40:00 */What are the most common bugs when working with Unix time?
Working with time is notoriously difficult. Here are the most common gotchas that keep developers up at night:
1. The Millisecond Trap
As mentioned earlier, passing seconds instead of milliseconds (or vice versa) to your date functions will result in wild date errors. If your date is showing up in 1970, check if you need to multiply by 1000. If your date is in the year 58000, you probably passed milliseconds to a function that expected seconds.
2. Timezone Assumptions
Unix timestamps are always in UTC. They have no concept of timezone.
The bug happens when you display the timestamp. If your database server is set to UTC, but your local development machine is set to EST, you might see different times for the same record. Always specify the timezone explicitly when formatting dates for users.
3. Daylight Saving Time (DST)
Unix time does not adjust for DST. One day has 86,400 seconds.
However, in the real world, the day when DST starts has only 82,800 seconds, and the day when it ends has 90,000 seconds. If you try to calculate “30 days from now” by doing 30 * 86400 seconds, your final hour might be off by one if you crossed a DST boundary.
4. Leap Seconds
To keep UTC aligned with the Earth’s rotation, scientists occasionally add a leap second to the calendar.
Unix time officially ignores leap seconds. The timestamp clock repeats the 60th second or inserts a duplicate second, which can cause real-time sync bugs in distributed systems if they are not running a modern NTP service that smears the leap second over several hours.
Why does my timestamp conversion output December 31, 1969?
If you try to convert a timestamp value of 0 (or a negative number, or a null/invalid value that defaults to 0), you might expect to see January 1, 1970.
However, if you live in the Western hemisphere (like the Americas), you will actually see: December 31, 1969, at 19:00:00 (or similar depending on your offset)
Why does this happen?
Remember that the Unix Epoch is defined in UTC. If you convert 0 to a date, it represents January 1, 1970, at 00:00:00 UTC.
When your programming language formats that date, it automatically translates it to your local timezone. If you are in New York (which is UTC-5), the system subtracts 5 hours from the epoch, bringing you back to the evening of December 31, 1969.
This is not a bug! It is just a timezone offset working exactly as designed.
Why did we build the TextSorter Timestamp Converter?
When you are debugging logs or checking database entries, you do not want to boot up a coding environment or write SQL queries just to read a timestamp. You need a fast, simple way to check the date.
There are many online epoch converters, but we found a couple of frustrating issues with them:
- Many of them upload your logs or timestamps to their servers for analytics. If you are copying a timestamp from a private system log or customer record, this is a privacy violation.
- They are often covered in slow ads and take forever to load.
That is why we built the TextSorter Timestamp Converter. It runs entirely on the client side inside your web browser.
When you paste a number, the JavaScript engine in your browser does the math instantly. No data is sent to our servers. Your logs, IP-related timestamps, and private records remain completely confidential.
Our tool also makes things easier by:
- Automatically detecting if your timestamp is in seconds (10 digits) or milliseconds (13 digits).
- Displaying the converted date in UTC, your local timezone, and relative human terms (like “in 2 hours” or “3 years ago”).
- Letting you convert human dates back into Unix timestamps in real time.
- Providing a quick “Current Time” button so you can get the exact current epoch value with one click.
Check it out at the TextSorter Timestamp Converter. It is lightweight, secure, and built to make your development workflow just a little bit easier.
FAQs about Unix timestamps
How do I get the current Unix timestamp in Unix/Linux command line?
You can get the current timestamp by opening your terminal and typing:
date +%sHow do I convert a timestamp to a date in the Linux terminal?
You can use the date command with the -d flag (on Linux/GNU systems):
date -d @1774896000On macOS (BSD systems), the syntax is slightly different:
date -r 1774896000Can Unix timestamps be negative?
Yes! A negative Unix timestamp represents a date before January 1, 1970. For example, a timestamp of -86400 represents December 31, 1969, at 00:00:00 UTC (exactly one day before the epoch). Most modern programming languages handle negative timestamps perfectly.
What is the maximum date a 64-bit Unix timestamp can represent?
A 64-bit timestamp can represent dates up to the year 292,277,026,596. You do not have to worry about your database clocks breaking for a very long time.
How does Unix time handle leap years?
Unix time handles leap years by ignoring leap seconds, but it does count the extra day in leap years. A leap year has 366 days, and Unix time increments by 86,400 seconds for every day of that year, ensuring that the alignment with the calendar year remains correct.