What a Unix timestamp is, in plain words
It is a counter. A stopwatch that started ticking on January 1st 1970 at midnight and has been running ever since. Every second that passes adds one. That is the whole idea.
The number 1746792000 means “1,746,792,000 seconds after that starting moment”. Plug it into any decent date tool and you get a real date, May 9th 2026.
Computers love this because a single integer is unambiguous. Two systems anywhere on the planet, given the same number, agree on the same exact instant. That is rare in software.
Why the same number shows different times
You and your friend in Tokyo both look at 1746792000 at the same moment. Your screen says 2pm Madrid time. Their screen says 9pm Tokyo. Same instant, different walls clocks.
The number itself never changes. What changes is how each device chooses to display it. New York rewinds it 6 hours, London leaves it as is, Tokyo pushes it forward 9.
Always store dates as the raw number. Show them in whatever timezone the reader cares about. If you store “May 9th 2pm” without saying which city, you have lost. Six months later nobody remembers if it was UTC, server time or whatever the laptop was set to.
The bug that bites half of all dates: seconds or milliseconds
Some systems count in seconds. Others count in milliseconds, which is a thousand times bigger. They look almost identical until you read them as a date.
1746792000 as seconds is May 2026. The same digits read as milliseconds become January 21st 1970, just after midnight. The whole project shows everyone’s birthday as if they were born last week.
You can spot the difference at a glance. A current timestamp in seconds has 10 digits. In milliseconds it has 13. Anything in between is probably wrong.
When a system gives you a timestamp and the docs do not say which one, paste it into the timestamp converter on AldeaCode. It detects the unit, shows the date in your timezone and in UTC at the same time, and never sends the value anywhere. Useful when an API contract just says “epoch” and you have to guess.
How browsers and JavaScript handle it
Three lines you will type a hundred times.
Math.floor(Date.now() / 1000); // current timestamp in seconds
new Date(1746792000 * 1000).toISOString(); // timestamp to readable UTC string
new Date("2026-05-09T12:00:00Z").getTime(); // string to millisecondsThe pattern: JavaScript talks in milliseconds, almost everything else talks in seconds. Multiply or divide by 1000 at the boundary. That is half of all the timestamp work you will ever do.
When you write a date as a string, always include the Z at the end (it means UTC) or an explicit offset like +02:00. A date string with nothing tacked on at the end is the second classic bug, because every browser parses it differently.
A 12 year old time bomb you should know about
In January 2038, an old way of storing timestamps will overflow. Code from the 1990s that uses 32 bit integers will start saying it is the year 1901 instead of 2038. Banks, payroll systems, embedded chips and ancient databases are still affected.
The fix is one line: use a bigger integer (64 bit) for the column. Most modern systems already did this 20 years ago. Some did not. If you maintain anything older than 2010, search the schema for INT columns holding dates and change them to BIGINT before someone else finds out.
This is not theoretical. The deadline is real, the date is fixed, and there is no extension.
Quick reference for common languages
# Bash
date -u +%s # current timestamp
date -u -d @1746792000 +%FT%TZ # timestamp to UTC string
# Python
import time; int(time.time())
# PostgreSQL
SELECT EXTRACT(EPOCH FROM NOW())::BIGINT;
SELECT TO_TIMESTAMP(1746792000) AT TIME ZONE 'UTC';
# Go
time.Now().Unix();
time.Unix(1746792000, 0).UTC();All of them work in seconds. None of them know which timezone you want to display the result in, that is the call you make at the very last step. If you live inside a database, the PostgreSQL timestamp converter and the MySQL timestamp converter show the equivalent TO_TIMESTAMP and FROM_UNIXTIME snippets next to a live conversion.
When you just need to inspect a timestamp without writing code, the timestamp converter does it instantly. Pair it with the JSON formatter when the timestamp is buried in a payload, and the UUID generator if you are building a new record from scratch. Three rules and you are done: store as the raw number, treat seconds versus milliseconds with respect, and pick the timezone at the moment you display.