Get Current Unix Timestamp in JavaScript, Python and SQL

To get the current Unix timestamp, use the number of seconds since 1970-01-01 00:00:00 UTC. In JavaScript, use Math.floor(Date.now() / 1000). In Python, use int(time.time()). In SQL, the expression depends on the database, and the sections below list the common ones.

If you want to check a value you already have, paste it into the Unix Timestamp Converter. It shows the matching UTC and local date, and it accepts both seconds and milliseconds.

What a Unix timestamp actually counts

A Unix timestamp is a count of elapsed time since the Unix epoch, 1970-01-01 00:00:00 UTC. The value does not depend on your time zone. The same moment produces the same number everywhere, which is why timestamps are common in APIs, logs and database columns.

The most important detail is the unit. Classic Unix timestamps count seconds. JavaScript's Date.now() returns milliseconds, and many APIs and logging tools also use milliseconds. A seconds value for the current date has 10 digits, such as 1718000000. A milliseconds value has 13 digits. If you mix them up, you get a date in 1970 or a date around the year 54,000. For a deeper look at the difference, see Unix Timestamp Seconds vs Milliseconds.

JavaScript

Date.now() returns the current time in milliseconds since the epoch as an integer. To get seconds, divide by 1000 and round down.

const ms = Date.now();
const seconds = Math.floor(Date.now() / 1000);
console.log(ms);
console.log(seconds);

Math.floor matters. Without it, Date.now() / 1000 returns a fractional number such as 1718000000.123, and many systems reject that or store it as a float. Math.floor is the clearest choice and works for every date after 1970.

You will sometimes see Math.trunc(x) or the bitwise shortcut x | 0 used for the same job. Math.trunc is fine. The | 0 form is a trap: bitwise OR converts its operand to a signed 32-bit integer, so it returns wrong values once the timestamp passes 2038-01-19 03:14:07 UTC. Avoid it for timestamps.

You can also write new Date().getTime(), which returns the same milliseconds value as Date.now(). Date.now() is shorter and avoids creating a Date object, so it is the usual choice.

Getting seconds from a Date object

const seconds = Math.floor(new Date().getTime() / 1000);

The result is the same as the Date.now() version. Use whichever reads better in your codebase.

Python

In Python, time.time() returns the current time as a float in seconds. Wrap it in int() to drop the fractional part.

import time

seconds = int(time.time())
print(seconds)

If you need milliseconds, use time.time_ns(), which is available from Python 3.7. Integer division by 1,000,000 converts nanoseconds to milliseconds without losing precision to floats.

import time

ms = time.time_ns() // 1_000_000
print(ms)

If you use the datetime module, be careful with the time zone. datetime.now().timestamp() treats a naive datetime as local time, so the result is correct only if the system clock and time zone are set as you expect. To avoid that, make the datetime timezone-aware in UTC.

from datetime import datetime, timezone

seconds = int(datetime.now(timezone.utc).timestamp())
print(seconds)

Both versions return the same value when the system clock is correct. The datetime version is easier to read when you already work with datetime objects.

SQL

SQL has no single standard function for the current Unix timestamp, so each database uses its own approach. The examples below return an integer number of seconds.

PostgreSQL

SELECT EXTRACT(EPOCH FROM now())::bigint;

EXTRACT(EPOCH FROM ...) returns a numeric value that includes fractional seconds, so the cast to bigint truncates it. now() returns the start time of the current transaction. If you want the time when the statement runs, use clock_timestamp().

MySQL and MariaDB

SELECT UNIX_TIMESTAMP();

UNIX_TIMESTAMP() with no argument returns the current time in seconds as an integer. It is one of the simplest cases in this list.

SQLite

SELECT CAST(strftime('%s', 'now') AS INTEGER);

strftime('%s', 'now') returns the seconds as text, so the cast to INTEGER is needed if you want a number. The 'now' value is UTC.

SQL Server

SELECT DATEDIFF_BIG(SECOND, '1970-01-01', SYSUTCDATETIME());

SQL Server has no direct Unix timestamp function. DATEDIFF_BIG counts the seconds between the epoch and the current UTC time and returns a bigint. Use it instead of DATEDIFF, which returns int. A plain DATEDIFF(SECOND, ...) call raises an arithmetic overflow error once the result passes 2147483647, which happens at 2038-01-19 03:14:07 UTC. DATEDIFF_BIG is available in SQL Server 2016 and later.

Use SYSUTCDATETIME() rather than GETDATE(). GETDATE() returns server local time, so the result is wrong on a server that is not set to UTC.

Common pitfalls

• Seconds vs milliseconds. Date.now() and many logging tools return milliseconds. Check the digit count before you store or compare values.
• Fractional seconds. Python's time.time() and PostgreSQL's EXTRACT(EPOCH ...) return decimals. Truncate them if your system expects an integer.
• Local time instead of UTC. The timestamp itself is always UTC-based, but converting a naive local datetime to a timestamp can shift the value by your time zone offset. Use UTC-aware code where possible.
• 32-bit overflow in code and storage. A signed 32-bit integer holds timestamps only up to 2038-01-19 03:14:07 UTC. This affects x | 0 in JavaScript, 32-bit INT columns, and SQL Server's DATEDIFF, which returns int. Use DATEDIFF_BIG and a 64-bit column such as BIGINT for new schemas.
• Using GETDATE() in SQL Server. It returns local server time. Use SYSUTCDATETIME() when you need UTC.

Checking the result

To confirm a value is correct, convert it back to a date. When the UTC date shown after conversion matches the current time in UTC within a few seconds, the value is correct. If the date is off by a few hours, look at your time zone handling. If it is off by decades, check the unit. You can run that check in the Unix Timestamp Converter by pasting the number directly.

FAQ

Is the Unix timestamp the same in every time zone?

Yes. The Unix timestamp counts seconds from 1970-01-01 00:00:00 UTC, so the same moment has the same value everywhere. Only the displayed date changes with the time zone.

Why does my timestamp have 13 digits?

It is most likely in milliseconds. Date.now() and many APIs return milliseconds. Divide by 1000 to get seconds, or see Unix Timestamp Seconds vs Milliseconds for how to tell which one you have.

Can I use the current timestamp to check a JWT expiry?

Yes. The exp claim in a JWT is a Unix timestamp in seconds, so you compare it with Math.floor(Date.now() / 1000) in JavaScript. You can read the claim with the JWT Decoder, which shows exp as a date. For the full check, see JWT Expiration Time: How to Check the exp Claim.