Working with Unix Timestamps: A Practical Developer Guide

What Is a Unix Timestamp, Exactly?

A Unix timestamp (also called epoch time) is the number of seconds elapsed since January 1, 1970, 00:00:00 UTC. That date is known as the Unix epoch. The value 0 means midnight on that exact date. A value like 1753689600 represents a specific moment in time — no ambiguity about timezones, no date format confusion, just a single integer.

This simplicity is what makes it so useful. Every major language and database supports it. You can pass it over an API, store it in a database column, or log it to a file without worrying about parsing.

Why Timestamps Matter

Unix timestamps show up everywhere in backend systems. Here are the common places you will encounter them:

• Database indexes. Storing creation/update times as integers is fast to index and compare. No string parsing overhead.
• API design. REST APIs frequently use timestamps in JSON responses. They are unambiguous across locales and timezones.
• Caching headers. HTTP Cache-Control and ETag values often derive from timestamp comparisons.
• Logging. Structured logs use epoch seconds so entries sort chronologically by default.

Here is a typical REST API response using timestamps. If you are debugging something like this, a JSON formatter can help you read the output cleanly:

{
  "id": 94827,
  "username": "jdoe",
  "created_at": 1753689600,
  "last_login": 1753776000,
  "subscription_expires": 1785225600
}

See how clean that is? Each field is just an integer. Compare it to trying to parse "2025-07-28T14:00:00Z" across a dozen different date formats and you will appreciate why timestamps are the default in so many backend systems.

The 32-bit Problem: January 19, 2038

This one matters. A signed 32-bit integer can hold values up to 2,147,483,647. When you plug that into a Unix timestamp, you get:

// The exact second the 32-bit timestamp overflows
// 2,147,483,647 = January 19, 2038 at 03:14:07 UTC

#include <stdio.h>
#include <time.h>

int main() {
    time_t t = 2147483647;  // Max signed 32-bit
    printf("%s", ctime(&t));
    // Output: Tue Jan 19 03:14:07 2038

    t = 2147483648;  // One second later - overflow!
    printf("%s", ctime(&t));
    // Output: Fri Dec 13 20:45:52 1901 (wrapped negative)
    return 0;
}

On a 32-bit system, that counter rolls over to a negative number and suddenly your "2040" date becomes "1901". Any system still running 32-bit time_t by 2038 is going to have a bad day. Most modern Linux and macOS systems have already moved to 64-bit time_t, but embedded devices, older legacy servers, and some Windows API calls still use 32-bit values.

If you are building anything with a long shelf life — financial systems, IoT firmware, certificate expiry logic — make sure your stack uses 64-bit timestamps.

Working with Timestamps in JavaScript

JavaScript is a bit weird with timestamps. The Date object internally stores time as milliseconds since the epoch, not seconds. This catches people off guard when they switch between JS and other languages.

Get current timestamp

// Current time in milliseconds (what JS uses internally)
const nowMs = Date.now();
console.log(nowMs); // e.g. 1753689600000

// Current time in seconds (what most APIs expect)
const nowSec = Math.floor(Date.now() / 1000);
console.log(nowSec); // e.g. 1753689600

Convert timestamp to readable date

const timestamp = 1753689600;

// Convert seconds to Date object (multiply by 1000!)
const date = new Date(timestamp * 1000);

console.log(date.toISOString());
// "2025-07-28T14:00:00.000Z"

console.log(date.toLocaleDateString('en-US', {
  weekday: 'long',
  year: 'numeric',
  month: 'long',
  day: 'numeric'
}));
// "Monday, July 28, 2025"

Convert date back to timestamp

const date = new Date('2025-07-28T14:00:00Z');

// Get seconds (divide by 1000)
const ts = Math.floor(date.getTime() / 1000);
console.log(ts); // 1753689600

Timezone pitfall

const ts = 1753689600;
const date = new Date(ts * 1000);

// These use LOCAL timezone - results differ per machine
console.log(date.toString());
// In UTC-5: "Mon Jul 28 2025 09:00:00 GMT-0500"

// Always use getUTC* methods for consistent results
console.log(date.getUTCFullYear());  // 2025
console.log(date.getUTCMonth());     // 6 (zero-indexed: July)
console.log(date.getUTCDate());      // 28
console.log(date.getUTCHours());     // 14

The biggest gotcha: new Date(timestamp) where timestamp is in seconds. JS will interpret it as milliseconds, giving you a date in January 1970. Always multiply seconds by 1000 before passing to new Date().

Working with Timestamps in Python

Python is more straightforward than JS here. The standard library uses seconds by default, which aligns with the Unix convention.

Get current timestamp

import time

now = time.time()
print(now)  # 1753689600.123456 (float with microsecond precision)

# Integer seconds
print(int(now))  # 1753689600

Convert timestamp to readable date

import time
from datetime import datetime

ts = 1753689600

# Using datetime (recommended)
dt_utc = datetime.fromtimestamp(ts, tz=timezone.utc)
print(dt_utc)
# 2025-07-28 14:00:00+00:00

# Using time module (simpler, UTC)
print(time.gmtime(ts))
# time.struct_time(tm_year=2025, tm_mon=7, tm_mday=28, ...)

# WARNING: without tz argument, fromtimestamp uses LOCAL timezone
dt_local = datetime.fromtimestamp(ts)
print(dt_local)  # Depends on your machine's timezone

Convert date to timestamp

from datetime import datetime, timezone

dt = datetime(2025, 7, 28, 14, 0, 0, tzinfo=timezone.utc)
ts = dt.timestamp()
print(int(ts))  # 1753689600

# From a string
dt = datetime.fromisoformat("2025-07-28T14:00:00+00:00")
print(int(dt.timestamp()))  # 1753689600

One thing that bites people: datetime.fromtimestamp() without a tz argument uses the system local timezone. If you want UTC, pass tz=timezone.utc explicitly. If you are writing server code, always be explicit about timezones — your local dev machine and the production server may not share one.

Working with Timestamps in Other Languages

The basics are the same everywhere. Here is a quick reference for a few more languages you might run into:

Go

now := time.Now().Unix()                    // seconds
nowMs := time.Now().UnixMilli()            // milliseconds

// Convert back
t := time.Unix(1753689600, 0)
fmt.Println(t.UTC())  // 2025-07-28 14:00:00 +0000 UTC

PHP

$now = time();                              // seconds
$date = date('Y-m-d H:i:s', 1753689600);   // "2025-07-28 14:00:00" (UTC)
$ts  = strtotime('2025-07-28 14:00:00');    // 1753689600

MySQL

SELECT UNIX_TIMESTAMP();                    -- current timestamp (seconds)
SELECT UNIX_TIMESTAMP('2025-07-28 14:00:00');  -- 1753689600
SELECT FROM_UNIXTIME(1753689600);          -- '2025-07-28 14:00:00'

Each of these languages defaults to seconds, except JavaScript. That mismatch is the source of more bugs than you would think.

Millisecond vs Second Timestamps

This is probably the most common source of timestamp bugs. Some systems use seconds (10 digits), others use milliseconds (13 digits). Mix them up and your dates will be off by a factor of 1000.

Quick way to tell which one you have:

function detectTimestampPrecision(ts) {
  if (ts > 1e12) return 'milliseconds';
  return 'seconds';
}

// 1753689600      -> 10 digits -> seconds
// 1753689600000   -> 13 digits -> milliseconds

Convert between them:

// Seconds to milliseconds
const ms = seconds * 1000;

// Milliseconds to seconds
const sec = Math.floor(milliseconds / 1000);

In Python:

# Seconds to milliseconds
ms = seconds * 1000

# Milliseconds to seconds
sec = ms // 1000

Some APIs return millisecond timestamps (Java, most JavaScript frameworks), while others return seconds (Python, Go, C). If you are integrating two systems, check the docs or inspect a sample value. A timestamp starting with 1 and having 13 digits is almost certainly milliseconds. If you need to work with different bases or representations, a number base converter can be handy for inspecting the raw values.

Pro tip: If a date in your app shows as "January 20, 1970", you almost certainly forgot to multiply seconds by 1000 in JavaScript, or you are dividing milliseconds by 1000 twice. I have done this more times than I care to admit.

Using an Online Timestamp Converter

Sometimes you just need a quick conversion without writing code. Maybe you are debugging an API response, checking a database record, or investigating a log file. Opening a code editor or REPL every time is slow.

That is where an online timestamp converter comes in. Paste a value, get a human-readable date instantly. No setup, no dependencies.

Common scenarios where I reach for a free Unix timestamp tool instead of code:

• Debugging API responses. You get a JSON payload from a third-party API and need to verify what created_at: 1753689600 actually means. Paste it into the converter and you know immediately.
• Checking database records. Running a query like SELECT * FROM users WHERE created_at > 1750000000 and want to confirm what date that threshold represents.
• Verifying test data. When writing unit tests that involve time windows, you need to know the exact date a given timestamp corresponds to.
• Cross-referencing logs. Log files often use different date formats. Converting a timestamp to a readable date helps you correlate events across systems.

The timestamp converter tool on UseEasyTool handles both seconds and milliseconds automatically, so you do not have to think about precision. It also shows the current timestamp live, which is useful when you need a reference value right now. Next time you are staring at a raw timestamp in a log file, give the online timestamp converter a try — it is faster than opening a terminal.

Quick Reference Cheat Sheet

Here is a table of the most common timestamp operations across JavaScript and Python, since those are the two languages where most of the confusion lives:

Bookmark this page or print the table. When you are switching between a Node.js frontend and a Python backend (which is half the teams I have worked on), this table saves you from the "is this seconds or milliseconds?" confusion at least twice a week.

If you also work with encoded data formats alongside timestamps, our Base64 encoder and other converter tools are worth a look for quick, code-free transformations.