Brightlane's logging system stores event times as timezone-naive timestamps, and the engineering team is verifying how a literal string parses into that type.
Write a query to return the string '2024-06-15 14:30:00' cast as a timezone-naive timestamp.
Output:
- A single row with one column,
event_time, 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
'2024-06-15 14:30:00'::TIMESTAMP AS event_time The shape
The ::timestamp cast resolves the literal as a timezone-naive TIMESTAMP, which stores the wall-clock reading exactly as written with no time zone attached. That is the right type for a logging system that already records every event in its own local frame.
Clause by clause
SELECT '2024-06-15 14:30:00'::timestamp AS event_timeevaluates the literal once and returns it as a singleTIMESTAMPvalue. The cast is what binds the result column toTIMESTAMP; without it, PostgreSQL would resolve the literal astextand the column type would be wrong even though the displayed value matches.- There is no
FROMbecause no table is being read; the literal supplies the value directly.
The trap
A bare '2024-06-15 14:30:00' looks like a timestamp but is a string. The result row will display the same characters, but the column's type is text, not TIMESTAMP, and any downstream operation that expects a real timestamp will either error out or trigger an implicit cast that depends on the session settings. The ::timestamp cast pins the destination type at write time, which is the only way to make the column safe to consume.
You practiced casting a literal datetime to TIMESTAMP — the type stores the wall-clock value as written, with no time zone attached.