Convert to Unix Time: A Practical 2026 Guide

You're probably here because you've got a timestamp from an API, a log line, a spreadsheet export, or a frontend bug report, and the value looks like nonsense. Something like 1672531200 or 1700000000000. One of them converts cleanly. The other might throw you straight into the wrong year if you handle it badly.

That's the part most quick guides skip. Converting a date to Unix time is easy. Converting it correctly, with the right unit and timezone assumptions, is where bugs show up. If you work with APIs, databases, analytics pipelines, JavaScript frontends, or even CSV imports, those mistakes pile up fast.

What Is Unix Time and Why Does It Matter

You'll usually first meet Unix time in the least friendly way possible. A backend returns a long integer. A database column stores dates as numbers. A file metadata field looks readable to the machine and useless to everyone else.

That number is Unix time. It's defined as the number of non-leap seconds elapsed since 00:00:00 UTC on January 1, 1970, which is the Unix epoch. A timestamp of 0 is exactly that moment, and Unix time increases by 1 for every non-leap second after it, as described in Wikipedia's Unix time reference.

Why engineers keep using it

The reason Unix time survives everywhere is simple. It turns time into an integer.

That matters because integers are easier to store, compare, sort, and pass between systems than formatted date strings. A log processor doesn't need to parse month names. A database can compare two timestamps without worrying about locale. An API can move time values across platforms without inventing a custom format.

Practical rule: Store machine time in a machine-friendly format, then render it for humans later.

What it solves and what it doesn't

Unix time helps you avoid a lot of messy calendar logic, but it doesn't magically remove every time-related problem. It gives you a universal reference point in UTC. That's useful for file modification times, network protocols, and logs because every system can agree on the same instant.

It does not carry a display timezone with it. It also doesn't tell you whether the source system gave you seconds or milliseconds. Those two problems cause far more real-world bugs than the basic conversion itself.

A good mental model is this:

Once you treat Unix time as a transport and storage format, the rest of the conversion rules start making sense.

The Fastest Way to Convert to Unix Time

If you just need an answer right now, use an online converter. That's the fastest route when you're checking an API response, validating a spreadsheet export, or translating a date for a teammate who doesn't want to write code.

A good converter should let you paste a human-readable date on one side and get the Unix timestamp on the other, and it should work both ways. If you browse free converter tools on Devnitys, you'll find options that are quicker than opening a REPL for one-off checks.

What to do in practice

For a quick convert to Unix time workflow, keep it simple:

1. Paste the full date and time you want to convert.
2. Check the timezone assumption before trusting the output.
3. Confirm the unit on the result, especially if you plan to pass it into JavaScript or an API.
4. Test the reverse conversion once, so you know the value round-trips correctly.

This matters more than people think. A converter that doesn't label units clearly can send you down the wrong path before you've even started debugging.

If the tool gives you a year that looks absurd, stop and check units first. Don't keep adjusting the date string.

If you want a visual walkthrough before touching code, this short demo helps:

When online tools are the right choice

Online converters are best for:

• Quick validation when an API returns a timestamp and you need to read it immediately.
• Cross-team communication when a marketer, analyst, or project manager needs the converted value without opening a terminal.
• Sanity checks before writing parsing logic into your app.

They're not the final answer for production systems. They're a fast checkpoint. For anything repeatable, you want conversion logic in code, tests, or the database layer.

How to Convert to Unix Time in Your Code

For production work, use your language's standard library whenever possible. Manual date math looks harmless until timezone handling, month boundaries, and parser behavior drift away from what you expected. Best practice is to use built-in functions such as Python's datetime.timestamp() or Go's time.Now().Unix() instead of hand-rolled calculations, because custom implementations can drift in high-precision systems, as noted in this Unix time guide.

JavaScript

JavaScript is where a lot of timestamp bugs start.

Its Date object works in milliseconds, not standard Unix seconds. That means Date.now() returns milliseconds, and if you feed a Unix timestamp in seconds directly into new Date(), JavaScript will interpret it as milliseconds and give you the wrong date. The fix is explicit: multiply Unix seconds by 1000 when constructing a Date, as described in this explanation of JavaScript date handling.

// Current Unix time in seconds
const unixSeconds = Math.floor(Date.now() / 1000);

// Convert a date string to Unix time in seconds
const unixFromDate = Math.floor(new Date('2026-10-28T17:00:00Z').getTime() / 1000);

// Convert Unix seconds back to a JavaScript Date
const date = new Date(unixFromDate * 1000);

console.log(unixSeconds);
console.log(unixFromDate);
console.log(date.toISOString());

The rule is easy to remember:

• JavaScript native time values are usually milliseconds
• Standard Unix timestamps are usually seconds

That mismatch is why frontend and backend teams often disagree about what the “same timestamp” means.

If you're debugging payloads before conversion, a JSON formatter makes it easier to spot whether a field is a short second-based value or a much longer millisecond-based value.

Don't guess based on the field name. I've seen timestamp, createdAt, and time used for both seconds and milliseconds.

Python

Python is much cleaner if you use timezone-aware datetimes.

from datetime import datetime, timezone

# Current Unix time in seconds
unix_now = int(datetime.now(timezone.utc).timestamp())

# Convert a specific UTC datetime to Unix time
dt = datetime(2026, 10, 28, 17, 0, 0, tzinfo=timezone.utc)
unix_value = int(dt.timestamp())

# Convert Unix time back to a datetime
converted = datetime.fromtimestamp(unix_value, tz=timezone.utc)

print(unix_now)
print(unix_value)
print(converted.isoformat())

The important part isn't the method name. It's the timezone awareness.

If you create a naive datetime object and assume it means UTC, your code may still behave according to local machine settings. That's how code works fine on one laptop and fails on a server in another region. Use timezone.utc explicitly when the value is meant to represent a universal instant.

Java

Java's modern date and time API is solid if you stay inside java.time.

import java.time.Instant;
import java.time.LocalDateTime;
import java.time.ZoneOffset;

public class UnixTimeExample {
    public static void main(String[] args) {
        long unixNow = Instant.now().getEpochSecond();

        long unixValue = LocalDateTime
                .of(2026, 10, 28, 17, 0, 0)
                .toEpochSecond(ZoneOffset.UTC);

        Instant converted = Instant.ofEpochSecond(unixValue);

        System.out.println(unixNow);
        System.out.println(unixValue);
        System.out.println(converted);
    }
}

Java gives you a clean separation between local date-time values and timezone-aware instants. Use that separation. If a value is meant to be shared across systems, convert it to an Instant or derive the epoch value with a defined offset such as ZoneOffset.UTC.

What works well in production

Code examples are the easy part. The harder part is setting rules that stop future mistakes.

Use these in real projects:

• Choose one storage unit. Pick seconds or milliseconds for an API or database field and document it.
• Convert at the boundary. If the frontend uses milliseconds and the backend stores seconds, normalize at the request and response layer.
• Store UTC instants. Apply user locale and timezone only when rendering.
• Round intentionally. If your system only supports seconds, use Math.floor, int(), or the equivalent on purpose rather than letting implicit conversion hide precision loss.

A lot of timestamp bugs don't come from broken code. They come from unstated assumptions between systems.

Unix Timestamps in Databases and Spreadsheets

Timestamps don't stay inside application code. They show up in SQL queries, exported CSVs, analytics dashboards, and spreadsheet tabs shared across half the company. That's where conversion shortcuts become tempting, and where sloppy assumptions create reporting errors.

SQL examples

Most databases give you built-in functions for Unix time conversion. Use them instead of rebuilding the math in every query.

MySQL

SELECT UNIX_TIMESTAMP('2026-10-28 17:00:00');
SELECT FROM_UNIXTIME(1793206800);

PostgreSQL

SELECT EXTRACT(EPOCH FROM TIMESTAMP '2026-10-28 17:00:00');
SELECT TO_TIMESTAMP(1793206800);

What matters here isn't memorizing function names. It's knowing what timezone context the database applies when it parses or formats values. If the database server, session, and application don't agree on timezone behavior, a valid query can still produce a misleading result.

Treat database conversion functions as reliable tools, but never treat timezone defaults as safe.

A practical habit is to standardize timestamps in UTC before they hit the database, then convert for display in the application or reporting layer.

Excel and Google Sheets

Spreadsheets don't think in Unix time by default. They think in date serial values. To convert a Unix timestamp in cell A1 into a readable date, the common formula is:

=(A1/86400)+DATE(1970,1,1)

Why that works:

• 86400 is the exact number of seconds in a UTC day, which is part of the core date-to-epoch calculation method described in the verified data.
• Dividing the timestamp by 86400 converts seconds into spreadsheet day units.
• Adding DATE(1970,1,1) shifts the value from the Unix epoch to the spreadsheet's date system.

If the result looks like a plain number, change the cell format to a date-time format.

This is also where milliseconds trip people up. If the imported value is in milliseconds, divide by 1000 first before applying the spreadsheet formula. Otherwise, your sheet won't be converting the intended instant at all.

What to watch in shared data work

Database and spreadsheet timestamp issues usually come from three places:

• Mixed units between export systems and reporting tools
• Silent timezone assumptions in database sessions or spreadsheet imports
• Human edits where someone pastes a formatted date over the raw timestamp field

For reporting pipelines, keep the raw epoch field intact and create separate formatted columns for analysts and stakeholders. That gives you a stable source of truth and a readable layer for everyone else.

Using the Command Line for Quick Conversions

If you live in the terminal, the date command is the fastest way to check Unix time without leaving your shell. It's useful for log review, shell scripts, and quick sanity checks during deployments.

Get the current Unix timestamp

On Linux and macOS, this gives you the current Unix timestamp:

date +%s

That's the command you'll use most often. It's fast, built in, and perfect for checking whether an app log or API payload lines up with the current system clock.

Convert a specific date in the terminal

For a specific UTC date, the exact syntax varies a bit by platform.

Linux example

date -u -d "2026-10-28 17:00:00" +%s

macOS example

date -u -j -f "%Y-%m-%d %H:%M:%S" "2026-10-28 17:00:00" +%s

To go the other direction and inspect a Unix timestamp:

Linux

date -u -d @1793206800

macOS

date -u -r 1793206800

The key detail is the -u flag. It tells the command to use UTC. Without it, your shell may interpret or display the value in local time, which is fine for local inspection but risky if you're trying to compare values across systems.

A terminal check won't replace proper application logic, but it's one of the quickest ways to verify whether the bug is in your data, your parser, or your display layer.

Avoiding Common Unix Timestamp Pitfalls

Most timestamp bugs aren't complicated. They're repetitive. The same two or three mistakes show up in APIs, dashboards, frontend code, and import scripts over and over.

Seconds and milliseconds are not interchangeable

This is the biggest gotcha when you convert to Unix time across frontend and backend systems. Standard Unix time is in seconds, but modern JavaScript environments often use milliseconds. That ambiguity causes frequent data corruption, and users regularly paste millisecond values such as 1700000000000 into second-based tools and get nonsense results, as noted by Textmagic's timestamp converter guide.

If a timestamp is unexpectedly huge, don't “fix” the date manually. Check whether you need to divide by 1000 first.

Unix time is UTC, not local time

Unix timestamps represent an instant in UTC. They do not carry a local timezone.

The bug usually happens earlier, during conversion from a partial or local date. If someone converts “3:00 PM” without an explicit date or timezone context, different systems can produce different epoch values. That's why event scheduling, survey tools, and anything cross-region can go wrong even when the raw timestamp math is technically valid.

Use local time for input and display. Use UTC for storage and transport.

If your app also handles authentication payloads, the same habit matters when inspecting token timestamps. A JWT decoding guide can help when you need to inspect time-based claims and verify how they're being interpreted.

Legacy storage still bites

There's one older problem worth keeping in mind. Many legacy systems stored timestamps in 32-bit signed integers, which cap out at 2,147,483,647 seconds. That corresponds to 03:14:07 UTC on January 19, 2038, after which values can overflow and wrap incorrectly. The standard fix is to use 64-bit integers, which extend the valid range to approximately 292 billion years in both directions, as explained in this overview of the Year 2038 problem and timestamp storage.

This doesn't hit every modern app, but it still matters in old schemas, embedded systems, and long-lived integrations.

The practical checklist is short:

• Label units explicitly in API fields and docs
• Normalize to UTC before storage
• Use standard library conversions instead of manual date math
• Prefer 64-bit timestamp storage for long-term safety

Get those four right and most Unix timestamp bugs disappear before they reach production.

---

Devnitys collects useful free web tools in one place, including utilities for developers, marketers, analysts, and everyday workflows. If you want a cleaner way to find practical online tools without signups or downloads, browse Devnitys.