# What Is a Unix Timestamp? (And Where You'll See One) > A Unix timestamp is the number of seconds since January 1, 1970, UTC. It is the universal time format for computers: small, sortable, timezone-independent, and trivially comparable. Here is what it is, where you will see one, the Year 2038 problem, and how to convert to and from a human-readable date in your browser. URL: https://uttir.com/blog/what-is-a-unix-timestamp-and-where-youll-see-one Published: 2026-08-22 Author: Uttir Reading time: 5 min Tags: time, developer-tools, unix, data, formatting ## Quick answer A Unix timestamp is a single integer that counts the seconds since January 1, 1970, 00:00:00 UTC. As of August 2026, it is around 1,780,000,000. To convert a timestamp to a human date, use a browser-based converter like the [Uttir Unix Timestamp Converter](/unix-timestamp-converter). To convert a human date to a timestamp, enter it in the converter. The format is universal across programming languages and time zones, which is why it is the default for databases, log files, and APIs. You are reading a log file. Every line starts with a number: `1724236800`. Or you are debugging an API. The response has a field called `created_at` with the value `1755782400`. Or you are looking at a database table. The `timestamp` column has values like `1716240000`. None of these look like dates. They are not. They are Unix timestamps. A Unix timestamp is a single integer: the number of seconds that have elapsed since January 1, 1970, at 00:00:00 UTC. That moment is called the Unix epoch. Every timestamp after that moment is a positive integer; every timestamp before is a negative integer. The current Unix timestamp (mid-2026) is around 1,780,000,000 — about 1.78 billion. By the time you read this, it will be a few million more. ## Why Unix timestamps exist Humans read time as a calendar date and a clock time: "August 21, 2026, 10:00 AM, in the timezone of Western Indonesia". That is six pieces of information. Computers prefer one. A Unix timestamp is a single integer that encodes all six: the integer alone determines the date, the time, and the timezone (UTC by definition, with conversion to a local timezone as a presentation choice). The other reason: a Unix timestamp is trivially comparable. Is time A before time B? Compare the integers. Is the difference between A and B more than 24 hours? Subtract and compare to 86400 (the number of seconds in a day). Is time A in the last hour? Subtract the current timestamp and compare to 3600. The operations are single CPU instructions; no parsing, no timezone math, no library calls. For this reason, Unix timestamps are the default time format in databases (PostgreSQL, MySQL, SQLite all support it natively), in log files (every major logging library uses it by default), and in APIs (REST APIs return timestamps as integers or as ISO 8601 strings, which are text-encoded versions of the same thing). ## Where you will see one Almost anywhere time is stored or transmitted between systems. The most common places: - **Database tables**. The `created_at`, `updated_at`, `deleted_at` columns are usually Unix timestamps. They index faster than date strings and they sort correctly without locale-specific collation. - **API responses**. JSON APIs return timestamps as integers (`1755782400`), as floats with millisecond precision (`1755782400.123`), or as ISO 8601 strings (`"2026-08-21T10:00:00Z"`). The first two are Unix timestamps; the third is a text encoding of the same value. - **Log files**. Every line of a log file starts with a timestamp. By default, the timestamp is a Unix timestamp; some loggers format it as a human-readable string for readability. - **File systems**. Most file systems store file modification times as Unix timestamps. The `ls -l` command shows them as human-readable dates, but the underlying value is an integer. - **Cookies**. HTTP cookies have an `Expires` field that is a human-readable date string, but the `Max-Age` field is a number of seconds (a delta, not a timestamp). - **JWT tokens**. The `exp` and `iat` (issued at) fields in a JSON Web Token are Unix timestamps. ## How to read a Unix timestamp You can do it in your head, but you do not have to. The math: the current timestamp is around 1,780,000,000 (mid-2026). To convert a timestamp to a date, divide by 86400 (seconds in a day) to get the number of days since the epoch, then add to January 1, 1970. To convert a date to a timestamp, do the reverse. It is faster to use a converter. The [Uttir Unix Timestamp Converter](/unix-timestamp-converter) does the conversion in both directions. Paste a timestamp, get a date. Paste a date, get a timestamp. The tool runs in the browser; the conversion is instant. For a list of common reference points, here are some landmarks: - `0` = January 1, 1970, 00:00:00 UTC (the epoch) - `946684800` = January 1, 2000, 00:00:00 UTC (the Y2K moment) - `1000000000` = September 9, 2001, 01:46:40 UTC (the first 10-digit timestamp; "billennium") - `1234567890` = February 13, 2009, 23:31:30 UTC (a popular choice for programmer humor) - `2147483647` = January 19, 2038, 03:14:07 UTC (the 32-bit signed integer maximum; the Year 2038 problem) ## Milliseconds vs seconds JavaScript and most modern systems use millisecond timestamps, not second timestamps. `Date.now()` in JavaScript returns milliseconds since the epoch, which is 1000x larger than the equivalent Unix timestamp. The number 1755782400000 is the same moment as 1755782400. Always check which one you are working with; a 1000x off-by-one error is a common bug. The conversion is a matter of multiplying or dividing by 1000. Some APIs and languages use seconds (PHP, Python traditionally, Unix tools), some use milliseconds (JavaScript, Java, most modern APIs), some use microseconds (some high-frequency trading systems). The [Uttir Unix Timestamp Converter](/unix-timestamp-converter) has a toggle to switch between second and millisecond precision. ## Timezones A Unix timestamp is always in UTC. There is no timezone in a timestamp. When you convert a timestamp to a human-readable date, the converter can present it in any timezone: UTC, your local timezone, US Eastern, Tokyo. The timestamp itself does not change; the presentation does. If you have two timestamps in two different timezones, they represent two specific moments; converting both to UTC gives you the actual time difference. This is the biggest source of confusion for people new to timestamps. A date string like "2026-08-21 10:00:00" is ambiguous without a timezone; a timestamp is not. If your database stores timestamps in UTC and your application presents them in the user's local timezone, every user sees the correct local time, even if they are in different timezones. The conversion is one line of code: `new Date(timestamp * 1000).toLocaleString("en-US", {timeZone: "America/New_York"})` or equivalent. ## The Year 2038 problem The Year 2038 problem is the Unix equivalent of Y2K. It affects systems that store Unix timestamps as 32-bit signed integers. The maximum value of a 32-bit signed integer is 2,147,483,647 (about 2.1 billion), which corresponds to January 19, 2038, 03:14:07 UTC. After that moment, a 32-bit signed integer overflows and wraps to a negative number, which the system interprets as a date in 1901 or 1970 or some other pre-epoch moment. Most modern systems use 64-bit integers for timestamps, which pushes the problem to about 292 billion years from now. The systems that are still at risk are embedded systems, old databases, and any code that was written in the 1990s and never updated. The fix is to migrate to 64-bit timestamps before January 19, 2038. Most major operating systems, databases, and languages have already done this; the remaining work is in legacy systems that have not been touched in 30 years. ## When not to use Unix timestamps For human-facing display, Unix timestamps are unreadable. `1755782400` does not mean anything to a person; "August 21, 2026, 10:00 AM" does. The right pattern is: store as Unix timestamp (or as ISO 8601 string in UTC), display as a localized date string. The conversion happens at the presentation layer, not the storage layer. For dates that need timezone arithmetic (e.g. "next Tuesday at 9 AM in the user's local timezone, every week"), Unix timestamps alone are not enough. You also need a timezone library (e.g. Luxon, date-fns-tz, Temporal) to handle the conversion. Storing as timestamp + timezone is the right answer; storing as timestamp alone forces you to assume a timezone, which breaks for users in other timezones. ## Related tools - [Unix Timestamp Converter](https://uttir.com/unix-timestamp-converter) — Convert Unix timestamps to readable dates and back, with a live current-time readout. - [Date Add/Subtract Calculator](https://uttir.com/date-add-subtract) — Add or subtract days, weeks, months, or years from any date. Handles month-end and leap-year rollovers. - [Date Calculator](https://uttir.com/date-calculator) — Count the days between two dates, or add and subtract days from any date. - [JSON Validator](https://uttir.com/json-validator) — Check whether your JSON is valid and find the exact line and column of any syntax error. - [JSON Formatter](https://uttir.com/json-formatter) — Format, beautify, and validate JSON with adjustable indentation — instantly in your browser. --- For the full HTML article, visit https://uttir.com/blog/what-is-a-unix-timestamp-and-where-youll-see-one. This file is the markdown rendering at https://uttir.com/blog/what-is-a-unix-timestamp-and-where-youll-see-one.md. See https://uttir.com/llms.txt for a site-wide summary.