Type dates the way you say them: last wed at 3, ytd

SQLly reads plain-language dates in a WHERE clause and writes the exact literal or BETWEEN range for your column, then keeps saved queries current in one click.

By Matt Van Horn October 23, 2026

Every SQL date filter starts with the same small arithmetic. What's the date of last Wednesday? Does November have 30 days or 31? If I write BETWEEN '2025-11-01' AND '2025-11-30' against a datetime column, do I lose everything that happened on the afternoon of the 30th? (You do.) None of it is hard, and all of it is a reason to stop typing and open a calendar.

SQLly now does that arithmetic for you. After a date comparison, press Ctrl+Shift+Space and type the date the way you would say it.

Say it, see it, press Enter

SELECT *
FROM Sales.Orders AS o
WHERE o.OrderDate = last wed at 3

A card opens under the line. Before you type, it shows what it understands: today, last wed at 3, november, ytd, past 7 days, q3 2025, from mon to fri and more. As you type, it shows what your phrase means and the SQL it will become. Press Enter:

WHERE o.OrderDate = '2026-10-21T15:00:00' --sqlly date:last wed at 3

The literal is written for the engine you're connected to and the column you're comparing: a plain date for a date column, the unambiguous T form on SQL Server, DATE and TIMESTAMP keywords on Oracle.

Periods become ranges, done right

Most of the dates we filter by aren't moments; they're periods. Today. November. Last week. Year to date. Compare a date column with one of those and SQLly writes the range:

WHERE o.OrderDate = november
-- becomes
WHERE o.OrderDate BETWEEN '2025-11-01T00:00:00' AND '2025-11-30T23:59:59.997' --sqlly date:november

That .997 isn't a typo. SQL Server's datetime stores time in 1/300-second ticks, so .999 rounds up into December 1st. SQLly looks up the column's type and writes the last moment that type can actually hold: .9999999 for datetime2, microseconds for a PostgreSQL timestamp, whole seconds for MySQL's default DATETIME, and just the last day for a date. If you'd rather not think about precision at all, switch to the half-open style and get (OrderDate >= '2025-11-01' AND OrderDate < '2025-12-01'), which is exact for any type.

The operator decides how the range is used. <> excludes the period, > november means after November, and < november means before it.

Saved queries that stay current

Here's the part I like most. The comment at the end of the line, --sqlly date:november, keeps your words. A query you saved as "orders from yesterday" shouldn't quietly turn into "orders from the 21st of October" forever.

Each comment gets a small ↻ button that re-evaluates that date against today.
A statement holding any of these dates gets a ↻ Refresh dates button that updates them all in one undoable edit.
Or turn on Refresh dates every time the query runs, and "yesterday" always means yesterday.

It's your calendar

Dates are full of conventions, so the conventions are settings, under Settings › Editor › IntelliSense › Date & time convenience. Does your week start on Sunday or Monday? Does "wed" mean the Wednesday that just passed or the one coming up? Is "at 3" in the afternoon (business hours, the default) or the middle of the night? Does "ytd" run to the end of today or to this exact second? When does your fiscal year start, so "this fiscal year" and "fytd" mean what your finance team means?

Everywhere else, Ctrl+Shift+Space still does what it always did: it looks up the column's real values. The date card only appears when you're comparing against a date.

The full list of phrases and every setting is in the docs: Natural-language dates.