Unix Epoch Cheat Sheet: Because I’m Tired of Googling This

A "no-fluff" reference guide for the terminal commands and code snippets we all forget. Written by a dev who has fixed one too many time-zone bugs.

Let’s be honest: nobody actually remembers the flags for the date command. We all just search for it, copy the snippet from a random forum, and move on. After doing that for the thousandth time, I decided to put everything in one place.

Unix time (or "Epoch time") is just a counter of seconds since New Year's Day, 1970. Simple, right? Until you realize half your stack is using milliseconds and the other half is using seconds, and suddenly your "Current Date" is showing up as the year 54,000.

The "Gimme a Timestamp" Snippets

If you're in a hurry and just need to grab the current epoch for your sanity check, here are the copy-paste snippets for the usual suspects:

The Linux/Mac Terminal:

date +%s

Command Prompt/ Windows Powershell:

powershell -Command "[int64](Get-Date -UFormat \""%s\"")"

Python (Always works):

import time print(int(time.time()))

JavaScript (The Node.js way):

Math.floor(Date.now() / 1000)

Go (Golang):

time.Now().Unix()

Java:

System.currentTimeMillis()
Wait! Check your digits: If your timestamp has 10 digits, it's seconds. If it has 13 digits, it's milliseconds (common in JS and Java). Don't let this break your backend logic!

Just need the timestamp or have a messy one to convert?

Skip the code and get the current time instantly. Our tool shows both 10-digit and 13-digit formats side-by-side, so you never have to guess which one your project needs.

⏱️ Open Epoch Converter Tool

Dealing with "Negative" Timestamps

Here is a fun one: Unix time didn't start at the beginning of the world; it started in 1970. So, what happens if you have a date from 1965? You get a negative number.

I’ve seen junior devs freak out seeing a negative result from a linux timestamp convert query. It's totally normal. Just make sure your database doesn't have an "Unsigned" constraint on that column, or you're going to have a very bad Friday deployment.

The 2038 "Time Bomb"

We have about 12 years left until the "Year 2038" problem hits. This is the Unix version of Y2K. On Jan 19, 2038, 32-bit systems will basically stop working because the integer will overflow. If you're still writing code that stores time in a 32-bit signed integer... please stop. Use 64-bit. Your future self will thank you.

Final Tip: Epoch vs. ISO 8601

Timestamps are great for computers, but they suck for logs. If you're writing to a log file, do everyone a favor and store the Epoch to Timestamp conversion alongside the raw number. It makes debugging 100x faster.

Got a massive project timeline to manage? You might also like my guide on Calculating the Difference Between Two Dates without losing your mind.