CURRENT_DATE

Syntax

How it works

CURRENT_DATE is the ANSI SQL function for "today". It returns a DATE value (year, month and day) and, unlike NOW(), it carries no hours, minutes or seconds. It is the natural building block for reports such as "orders placed today" or "invoices due this week".

Support differs by engine. PostgreSQL and MySQL both implement the ANSI keyword CURRENT_DATE (MySQL also accepts CURRENT_DATE() and the alias CURDATE()). SQLite has no CURRENT_DATE function call but does expose CURRENT_DATE as a special keyword, and DATE('now') is the idiomatic form. SQL Server has no CURRENT_DATE at all: use CAST(GETDATE() AS DATE) (or CAST(SYSDATETIME() AS DATE)).

The value reflects the clock and time zone of the database server, not the client. In PostgreSQL CURRENT_DATE honours the session time zone, while in MySQL it follows the session time_zone setting. Because a date rolls over at midnight, running the same query either side of midnight (or in a different time zone) can return a different day, so store timestamps carefully and be explicit about UTC when it matters. See all SQL functions for related date and time helpers.

Examples

Get today's date

SELECT CURRENT_DATE AS today;

today
----------
2026-07-05

Filter rows created today

-- created_at is a DATE column here
SELECT id, customer_id, total
FROM orders
WHERE created_at = CURRENT_DATE;

id  | customer_id | total
----+-------------+-------
 91 |         12  | 40.00
 92 |         34  | 15.50

Compute days until a due date

SELECT id,
       due_date,
       due_date - CURRENT_DATE AS days_left
FROM invoices
WHERE status = 'open'
ORDER BY days_left;

id | due_date   | days_left
---+------------+----------
 7 | 2026-07-06 |         1
 3 | 2026-07-10 |         5
 9 | 2026-07-20 |        15

Per-engine equivalents for today

-- PostgreSQL / MySQL (ANSI)
SELECT CURRENT_DATE;

-- MySQL alias
SELECT CURDATE();

-- SQL Server (no CURRENT_DATE)
SELECT CAST(GETDATE() AS DATE);

-- SQLite
SELECT DATE('now');

today
----------
2026-07-05

Rows created today from a DATETIME column

-- created_at stores a full timestamp, so use a range
SELECT COUNT(*) AS orders_today
FROM orders
WHERE created_at >= CURRENT_DATE
  AND created_at <  CURRENT_DATE + INTERVAL '1' DAY;

orders_today
------------
         37

Common mistakes

-- created_at is a DATETIME. This only matches rows
-- stamped at exactly midnight, missing the rest of today.
SELECT *
FROM orders
WHERE created_at = CURRENT_DATE;

-- Use a half-open range so every time today is included
SELECT *
FROM orders
WHERE created_at >= CURRENT_DATE
  AND created_at <  CURRENT_DATE + INTERVAL '1' DAY;

-- Fails on SQL Server: CURRENT_DATE does not exist
SELECT CURRENT_DATE;

-- SQL Server: cast the current timestamp to DATE
SELECT CAST(GETDATE() AS DATE);

-- Assumes the server clock matches the user's zone.
-- Near midnight this can report the wrong day.
SELECT *
FROM events
WHERE event_date = CURRENT_DATE;

-- Be explicit about the time zone you mean, e.g. UTC
SELECT *
FROM events
WHERE event_date = (CURRENT_TIMESTAMP AT TIME ZONE 'UTC')::date;

Performance

CURRENT_DATE itself is trivially cheap: it is evaluated once per statement, not once per row, so there is no per-row cost to referencing it in a WHERE clause.

The real performance question is whether your filter can use an index. A predicate like created_at >= CURRENT_DATE AND created_at < CURRENT_DATE + INTERVAL '1' DAY is sargable and can use an index on created_at. Wrapping the column in a function, such as CAST(created_at AS DATE) = CURRENT_DATE, usually defeats the index and forces a full scan.

For repeated "today" reporting on large tables, keeping the range form lets the optimiser do an index range scan. See the indexing guide for why sargable predicates matter.

Interview questions

SELECT CAST(GETDATE() AS DATE) AS today;

SELECT * FROM orders
WHERE created_at >= CURRENT_DATE
  AND created_at <  CURRENT_DATE + INTERVAL '1' DAY;