How to Get Current Date in SQL

Use the current date functions when your query needs today’s date or the current timestamp for filtering, inserts, reporting, or time-based business logic. The exact function name varies slightly by database.

What you’ll build or solve

You’ll learn how to get the current date in SQL using standard and database-specific functions. You’ll also know when to use the full timestamp instead of just the date.

When this approach works best

This approach is the right choice when queries depend on “today” or “right now.”

Common real-world scenarios include:

• Today’s orders
• Expired subscriptions
• Audit inserts
• Session expiry checks
• Rolling dashboard filters

This is a bad idea when the application layer already controls timezones and business-day boundaries more accurately.

Prerequisites

You only need:

• Basic SELECT and WHERE knowledge
• A table with date or timestamp columns if filtering

Step-by-step instructions

Step 1: Use the current date function for your database

The SQL-standard current date is:

SELECT CURRENT_DATE;

This returns only the date.

For full timestamp precision, use:

SELECT CURRENT_TIMESTAMP;

This includes both date and time.

This is especially useful in filters.

SELECT *
FROM orders
WHERE created_at >= CURRENT_DATE;

What to look for:

• CURRENT_DATE returns today’s date
• CURRENT_TIMESTAMP includes time
• Great for rolling filters
• Usually timezone-aware to the DB session
• Prefer app-controlled timezones for user-facing logic

Examples you can copy

Today’s users

SELECT *
FROM users
WHERE signup_date = CURRENT_DATE;

Active subscriptions

SELECT *
FROM subscriptions
WHERE expires_at > CURRENT_TIMESTAMP;

Insert created date

INSERT INTO logs (created_at)
VALUES (CURRENT_TIMESTAMP);

Common mistakes and how to fix them

Mistake 1: Comparing timestamps directly to CURRENT_DATE

What the reader might do:

WHERE created_at = CURRENT_DATE

Why it breaks: timestamp columns often include time, so exact equality may miss rows.

Corrected approach:

Use a range filter.

WHERE created_at >= CURRENT_DATE
AND created_at < CURRENT_DATE + INTERVAL '1 day'

Mistake 2: Using database time for user-local dashboards

What the reader might do:

Rely on CURRENT_DATE for a global dashboard.

Why it breaks: the DB timezone may differ from the user’s local date.

Corrected approach:

Normalize timezone logic in the application or session.

Mistake 3: Using string dates instead of current functions

What the reader might do:

WHERE created_at >= '2026-04-14'

Why it breaks: this hardcodes the date.

Corrected approach:

Use dynamic current-date functions.

Troubleshooting

If today’s rows are missing, check timestamp vs date comparisons.

If time looks off, verify the DB session timezone.

If the filter should include time, switch to CURRENT_TIMESTAMP.

If user-local days matter, move timezone logic to the app layer.

Quick recap

• Use CURRENT_DATE for today
• Use CURRENT_TIMESTAMP for date + time
• Great for rolling filters and inserts
• Be careful with timestamp equality
• Watch timezone behavior