MySQL · Postgres · BigQuery · Snowflake · SQLite · DuckDB

The same date query, every SQL dialect.

Date arithmetic, DATE_TRUNC, formatting, "days between", generate-series, time zones — each shown side by side across six databases. Switch warehouses without re-learning the date functions every time.

15 recipes

Why this exists

Every warehouse spells dates differently.

Move from Postgres to BigQuery, or Snowflake to DuckDB, and the date functions you know stop working — wrong name, wrong argument order, or a builtin that simply isn't there. datesql.pages.dev puts the same task next to each other in six dialects, so you copy the one for your engine and move on — with notes on the gotchas (argument order, boundary counting, DATE vs TIMESTAMP) that quietly produce wrong numbers.

How it works

Find the task, copy your dialect, run it

  1. Pick a recipe. Browse by task in the full recipe list.
  2. Copy your dialect's block. Each recipe has MySQL, Postgres, BigQuery, Snowflake, SQLite and DuckDB versions.
  3. Mind the note. Each recipe flags the per-dialect gotcha so you don't ship an off-by-one date.

FAQ

Frequently asked questions

Are these SQL recipes free?

Yes. Every recipe on datesql.pages.dev is free to read and copy, with no account, paywall, or sign-up. Some outbound links (for example to data tools or warehouses) may be affiliate links, which never change the price you pay.

Which SQL dialects are covered?

Each recipe shows the same task in MySQL, PostgreSQL, BigQuery, Snowflake, SQLite and DuckDB — the six engines analysts and engineers switch between most. Where a dialect lacks a clean builtin, the recipe gives the correct workaround.

Why do date functions differ so much between databases?

There is no single SQL standard everyone follows for dates — MySQL has DATE_ADD, Snowflake has DATEADD, BigQuery has DATE_ADD with a different argument order, Postgres uses INTERVAL math, SQLite uses string modifiers. That mismatch is exactly what these side-by-side recipes solve.

Why does DATEDIFF give different answers in different dialects?

Two reasons: argument order (MySQL is DATEDIFF(end, start); Snowflake/BigQuery put the unit first and start before end), and boundary counting (some count crossed boundaries, not full units). Each recipe notes the order and whether it counts whole units — see the date-difference and age recipes.

Date vs DATETIME vs TIMESTAMP — does it matter?

Yes. A DATE has no time; TIMESTAMP/DATETIME do, and time zones only apply to timestamp types. Recipes note when a function needs a date vs a timestamp, and the time-zone recipe covers converting between zones.

How do I truncate a timestamp to the month?

Most engines have DATE_TRUNC (Postgres/Snowflake/DuckDB: DATE_TRUNC('month', d); BigQuery: DATE_TRUNC(d, MONTH)). MySQL has no DATE_TRUNC — use DATE_FORMAT(d, '%Y-%m-01'); SQLite uses date(d, 'start of month'). The date_trunc recipe shows all of them.