Mark Evans, VP Operations, is preparing a November review. He wants two numbers: how many orders Cartwheel took in November 2025, and how quickly support resolved tickets. Both are date questions, and SQLite handles dates differently from most databases. Once you see how, it’s simple and predictable.
\nSQLite has no separate date type. Cartwheel stores order_date as ISO-8601 text: '2025-11-28 19:55:30'. Because the format runs from largest unit to smallest, alphabetical order is chronological order. Comparing strings compares moments in time, and an index on the column works for date ranges.
Here’s the obvious November query:
\nSELECT COUNT(*) AS november_orders\nFROM orders\nWHERE order_date BETWEEN '2025-11-01' AND '2025-11-30';336 orders. It’s wrong by 11.
\n'2025-11-30' is shorter than '2025-11-30 19:55:30', and a shorter string that matches the start sorts first. So the upper bound is effectively midnight at the start of 30 November, and everything later that day falls outside. The fix is a half-open range: include the start, exclude the start of the next period.
SELECT COUNT(*) AS november_orders\nFROM orders\nWHERE order_date >= '2025-11-01'\n AND order_date < '2025-12-01';347, the real number. On the busiest days of the Black Friday weekend, those 11 missing orders would be a visible hole in Mark’s chart.
\n\nstrftime(format, value) returns parts of a date as text:
| Format | \nReturns | \nExample | \n
|---|---|---|
'%Y-%m' | \nyear and month | \n'2025-11' | \n
'%Y' | \nyear | \n'2025' | \n
'%w' | \nweekday, 0 = Sunday | \n'5' | \n
'%H' | \nhour, 00–23 | \n'19' | \n
'%Y-%m' is the workhorse: it turns a timestamp into a month label you can group by in the next lesson. Because the result is text, compare it with text: strftime('%w', order_date) = '0' finds Sunday orders, while = 0 finds nothing.
date() and datetime() normalise a value and accept modifiers, which make period boundaries easy:
SELECT\n date('2025-11-28 19:55:30') AS just_the_date,\n date('2025-11-28', 'start of month') AS month_start,\n date('2025-11-28', 'start of month', '+1 month') AS next_month_start,\n date('2025-11-28', 'start of month', '+1 month', '-1 day') AS month_end,\n date('2025-11-28', '-6 days') AS week_ago;Modifiers apply left to right. 'start of month', '+1 month' is exactly the exclusive upper bound a half-open range needs.
“Orders in the last 30 days” is a rolling window, and it hides an off-by-one question: does “last 30 days” as of 31 December include the 31st? Usually yes, which means the window starts on 2 December, 29 days earlier. Build both bounds from the anchor date so the window moves with it:
\nSELECT COUNT(*) AS orders_last_30_days\nFROM orders\nWHERE order_date >= date('2025-12-31', '-29 days')\n AND order_date < date('2025-12-31', '+1 day');189 orders. The upper bound is the start of the day after the anchor, the same half-open idea as before. Write the window’s first and last day in a comment above the query; whoever reviews it will check exactly that.
\nWeekday analysis combines strftime('%w', ...) with the CASE expressions from the previous lesson. Mapping ‘0’ and ‘6’ to weekend labels is a common first cut when marketing asks whether weekend campaigns are worth it:
SELECT\n order_id,\n order_date,\n CASE strftime('%w', order_date)\n WHEN '0' THEN 'weekend'\n WHEN '6' THEN 'weekend'\n ELSE 'weekday'\n END AS day_type\nFROM orders\nORDER BY order_date DESC\nLIMIT 5;This CASE uses the simple form, CASE value WHEN x THEN ..., which compares one value against a list. It’s handy for mappings like this one; use the searched form, CASE WHEN condition THEN ..., whenever a branch needs a real condition.
julianday() converts a date to a number of days (with fractions for the time). Subtract two and you have a duration in days; multiply by 24 for hours. Here are December’s urgent tickets with their resolution times:
SELECT\n ticket_id,\n opened_at,\n closed_at,\n ROUND((julianday(closed_at) - julianday(opened_at)) * 24, 1) AS hours_to_close\nFROM support_tickets\nWHERE priority = 'urgent'\n AND opened_at >= '2025-12-01'\nORDER BY opened_at;Ticket 691 has no closed_at, so its duration is NULL. That’s correct: it isn’t zero hours, it’s unfinished, and any average you compute later will skip it rather than flatter the team.
You can now filter and measure time. Mark’s other question, average resolution time per priority, needs one more idea: collapsing many rows into one per group. That’s next.
\n","toc":[{"id":"sec-1","text":"Dates are text, and that’s fine","level":2},{"id":"sec-2","text":"Pulling dates apart","level":2},{"id":"sec-3","text":"Rolling windows and weekdays","level":2},{"id":"sec-4","text":"Measuring durations","level":2}],"takeaways":["SQLite stores dates as ISO-8601 text, which sorts chronologically, so plain string comparison works as a date filter.","Filter a period with a half-open range (>= start AND < next start); BETWEEN with a date-only upper bound drops everything after midnight on the last day.","strftime() extracts parts like the month (‘%Y-%m’), weekday (‘%w’, 0 = Sunday) or hour (‘%H’) as text.","julianday(later) - julianday(earlier) gives a duration in fractional days; multiply by 24 for hours.","Anchor “as of” calculations on a fixed date instead of ‘now’ so the same query gives the same answer tomorrow."],"further":[{"title":"SQLite date and time functions","url":"https://www.sqlite.org/lang_datefunc.html"},{"title":"PostgreSQL date/time functions and operators","url":"https://www.postgresql.org/docs/current/functions-datetime.html"}],"quiz":[{"q":"order_date holds values like ‘2025-11-30 19:55:30’. Which filter returns every order placed in November 2025?
order_date BETWEEN '2025-11-01' AND '2025-11-30'","why":"‘2025-11-30 19:55:30’ sorts after ‘2025-11-30’, so every order on 30 November after midnight is dropped."},{"text":"order_date >= '2025-11-01' AND order_date < '2025-12-01'","why":"Correct. A half-open range includes all of the last day, whatever the time, and works the same for any period length."},{"text":"order_date > '2025-11-01' AND order_date < '2025-11-30'","why":"This loses all of 30 November: every ‘2025-11-30 …’ value sorts after ‘2025-11-30’, so < '2025-11-30' rejects it. The first day survives only because times sort after the bare date."},{"text":"order_date = '2025-11'","why":"Equality compares the full text, and no value is exactly ‘2025-11’."}],"answer":1},{"q":"What does strftime('%m', '2025-03-09 14:00:00') return?
CAST(... AS INTEGER) if you need a number."},{"text":"The text ‘March’","why":"SQLite’s strftime has no month-name format; you’d build names with a CASE expression."}],"answer":1},{"q":"A ticket opened at ‘2025-12-04 17:56:18’ and closed at ‘2025-12-05 01:56:18’. What does (julianday(closed_at) - julianday(opened_at)) * 24 return?
You compute customer tenure with julianday('now') - julianday(signup_date). Why might a colleague object?
Mark wants every ticket opened in November 2025 with its resolution time in hours.
\nReturn ticket_id, priority and hours_to_close (rounded to 1 decimal; leave it NULL for tickets that are still open), sorted by ticket_id. Order matters.
The starter has two bugs: one drops tickets, the other gets the unit wrong.
\n","hints":["Compare the starter’s row count with a count usingopened_at < '2025-12-01'. Which day goes missing?","Replace BETWEEN with a half-open range: >= '2025-11-01' AND < '2025-12-01'.","julianday() differences are in days. Multiply the difference by 24 before rounding."],"explanation":"With BETWEEN, the upper bound ‘2025-11-30’ sorts before any time on 30 November, so tickets opened that day vanish: 112 rows instead of 116. The half-open range keeps them. julianday(closed_at) - julianday(opened_at) is a fraction of a day, so multiplying by 24 gives hours. Open tickets have a NULL closed_at, and the arithmetic passes that NULL through, which is the honest answer for an unfinished ticket.