Time/Numbers

Unix Timestamp ↔ Date

Convert Unix time to a date and back, with support for arbitrary (IANA) time zones.


                    

Unix time (epoch time) is the number of seconds elapsed since January 1, 1970, 00:00:00 UTC. It's the most common way to store time in databases, APIs, and logs, since it's just a single integer with no tie to a specific timezone or date format.

How to use it

Common uses

Things to keep in mind

Mixing up seconds and milliseconds is the most common mistake: JavaScript's Date.now() returns milliseconds, while most Unix APIs use seconds — a factor of 1000 off.

Unix time itself has no timezone — it's always UTC; a timezone is only applied when displaying the date to a person.

Article about this tool: Unix time: why computers count time from 1970

Frequently asked questions

What is a Unix timestamp?

It's the number of seconds that have passed since January 1, 1970, 00:00:00 UTC (the Unix epoch). This number isn't tied to any timezone — the timezone is only applied when displaying the date to a person.

What's the difference between seconds and milliseconds?

JavaScript and some APIs (like Date.now()) return a timestamp in milliseconds, while the classic Unix time is in seconds. Mixing up the unit gives a date either in 1970 or somewhere in the distant future — pick the right unit in the "Units" field.

What is the Year 2038 problem?

On systems where a timestamp is stored as a signed 32-bit integer, the seconds counter will overflow on January 19, 2038. Modern 64-bit systems don't have this problem.

Does Unix time account for leap seconds?

No, every day in Unix time always equals exactly 86400 seconds, and leap seconds are ignored. Systems that need precise synchronization with astronomical UTC handle leap seconds through a separate mechanism outside the standard Unix timestamp.

Can Unix timestamps be negative?

Yes, negative values correspond to dates before January 1, 1970. Most modern systems handle such values correctly, though some older APIs or libraries may not support them.

Articles: Time/Numbers

Cron expressions: how to decode a task schedule

How to decode an expression like */15 * * * * and know exactly when the job will run.

Number systems: why binary, octal, and hexadecimal exist

Why the color #FF5733 in CSS is written in hexadecimal digits instead of decimal.

Bitwise operations: how AND, OR, and XOR work at the bit level

How bitwise AND differs from logical AND, and why you'd operate on individual bits of a number at all.

Date difference: why counting days is trickier than it looks

Why naively subtracting dates can give the wrong result because of leap years.

Age calculation: why it's not just subtracting years

Why simply subtracting birth years can give an age one year higher than the real one.

Time zones: why UTC isn't the same thing as GMT

Why UTC never changes twice a year, while London time (GMT/BST) does.

Duration calculator: how to correctly add up hours, minutes, and seconds

Why adding minutes and seconds requires "carrying" the remainder to the next place, just like in decimal addition.

ISO 8601 duration: how to write a duration in a standard format

Why PT1H30M means "1 hour 30 minutes," not "1 minute 30 hours."

Week number: why different countries count weeks differently

Why January 1 sometimes falls into week 52 or 53 of the previous year under the ISO 8601 standard.

Roman numerals: how a system with no zero and no place value works

Why IV means 4, not 6, and how the subtraction rule works in Roman numerals.

IEEE 754: why 0.1 + 0.2 doesn't equal 0.3 in code

Why almost every programming language prints 0.1 + 0.2 as 0.30000000000000004.

Number to words: why turn digits into text

Why bank documents write an amount both in digits and in words at the same time.