Brightlane's content licensing system computes contract expiry dates with a 1 year 6 month term.
Write a query to return the expiry date for a contract that begins on '2024-01-15', computed as the start date plus 1 year and 6 months.
Output:
- A single row with one column,
expiry_date, containing the resulting date.
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
'2024-01-15'::date + INTERVAL '1 year 6 months' AS expiry_date The shape
INTERVAL '1 year 6 months' is a single duration with two calendar components, and adding it to a date advances the year and the month independently. The contract starting on January 15, 2024 expires on July 15, 2025.
Clause by clause
SELECT '2024-01-15'::date + INTERVAL '1 year 6 months' AS expiry_datebuilds the expiry. The::datecast types the literal as a calendar date. The multi-componentINTERVALliteral declares both pieces of the duration in one quoted string, separated by spaces. PostgreSQL applies the year component and the month component together: one year forward from January 2024 reaches January 2025, then six more months reaches July 2025, with the day-of-month preserved throughout. The aliasAS expiry_datelabels the output.
Why one INTERVAL and not two additions
The two forms produce the same result. Writing '2024-01-15'::date + INTERVAL '1 year' + INTERVAL '6 months' chains two additions and lands on the same expiry. The single-literal form is more compact, names the full term as one duration, and matches how contract terms are usually expressed in the business. Either reads correctly. When the duration has a natural domain meaning, like a one-and-a-half-year term, expressing it as one literal keeps the SQL close to the spec.
You practiced multi-component INTERVAL literals like '1 year 6 months' — PostgreSQL applies each calendar component cumulatively from the source date.