Brightlane's reporting pipeline assigns each event to its calendar month for period-based grouping.
Write a query to return the month boundary produced by truncating the timestamp '2024-03-15 14:32:07' to month precision.
Output:
- A single row with one column,
month_start, typed as a timezone-naive timestamp.
Schema · ecommerce 5 tables
Run previews · Check grades
Write a query, then run it to see results here.
Worked solution Try it yourself first
SELECT
DATE_TRUNC('month', '2024-03-15 14:32:07'::TIMESTAMP) AS month_start The shape
DATE_TRUNC('month', ...) rounds a datetime down to the first instant of its calendar month and returns a datetime. The March 15 timestamp lands on '2024-03-01 00:00:00', which is the period boundary the reporting pipeline keys events against.
Clause by clause
SELECT DATE_TRUNC('month', '2024-03-15 14:32:07'::timestamp)evaluates the truncation against a single literal value. The::timestampcast resolves the string as a timezone-naive timestamp soDATE_TRUNCreturns atimestampof the same flavor. Without the explicit cast, PostgreSQL would have to infer the input type and the result type would follow whatever inference it landed on.AS month_startlabels the output column so the row reads as a domain value rather than a function expression. There is noFROMbecause the value comes straight from the prompt as a literal.
The trap
The result keeps the full timestamp shape, not just a date. DATE_TRUNC('month', ...) returns '2024-03-01 00:00:00', not '2024-03-01', and its type is timestamp, not date. Any consumer expecting a bare calendar date will need an explicit ::date cast on the output. The function name reads like "give me the month," but what it gives is the start-of-month instant, which is the value that makes two timestamps from anywhere inside March compare as equal.
You practiced DATE_TRUNC('month', ...) — collapse every datetime within a calendar month to the same start-of-month boundary, the standard shape for grouping events by period.