Date, time, and timestamp types in PostgreSQL - Time & Space Complexity

Time Complexity: Date, time, and timestamp types

O(n)

Understanding Time Complexity

We want to understand how the time it takes to work with date and time types changes as we handle more data.

Specifically, how does the processing time grow when using date, time, or timestamp fields in queries?

Scenario Under Consideration

Analyze the time complexity of the following query filtering rows by a timestamp range.

SELECT *
FROM events
WHERE event_time >= '2024-01-01 00:00:00'
  AND event_time < '2024-02-01 00:00:00';
    

This query selects all events that happened in January 2024 by checking the timestamp column.

Identify Repeating Operations

Look for repeated checks or scans in the query.

• Primary operation: Scanning each row's event_time to check if it falls in the date range.
• How many times: Once per row in the events table.

How Execution Grows With Input

As the number of rows grows, the number of timestamp checks grows too.

Input Size (n rows)	Approx. Operations (timestamp checks)
10	10
100	100
1000	1000

Pattern observation: The number of operations grows directly with the number of rows.

Final Time Complexity

Time Complexity: O(n)

This means the time to run the query grows in a straight line as the number of rows increases.

Common Mistake

[X] Wrong: "Checking timestamps is instant and does not depend on data size."

[OK] Correct: Each row's timestamp must be checked, so more rows mean more checks and more time.

Interview Connect

Understanding how filtering by date or time scales helps you write efficient queries and explain performance clearly.

Self-Check

"What if we add an index on the event_time column? How would the time complexity change?"

Practice

1. Which PostgreSQL data type should you use to store only the date without any time information?

easy

A. TIMESTAMP

B. TIME

C. INTERVAL

D. DATE

Solution

1. Step 1: Understand the data types

   DATE stores only the calendar date (year, month, day) without time.

2. Step 2: Match the requirement

   Since we want only the date without time, DATE is the correct choice.

3. Final Answer:

   DATE -> Option D

4. Quick Check:

   Date only = DATE [OK]

Hint: Use DATE for day only, no time needed [OK]

Common Mistakes:

• Choosing TIMESTAMP which includes time
• Using TIME which stores only time
• Confusing INTERVAL with date storage

2. Which of the following is the correct way to declare a column named created_at that stores date and time with time zone in PostgreSQL?

easy

A. created_at TIMESTAMP WITH TIME ZONE

B. created_at TIMESTAMP

C. created_at DATE WITH TIME ZONE

D. created_at TIME WITH TIME ZONE

Solution

1. Step 1: Identify the correct type for date and time with time zone

   PostgreSQL uses TIMESTAMP WITH TIME ZONE to store both date and time including time zone info.

2. Step 2: Check the options

   created_at TIMESTAMP WITH TIME ZONE matches the correct syntax and type. The other options are either missing time zone or invalid.

3. Final Answer:

   created_at TIMESTAMP WITH TIME ZONE -> Option A

4. Quick Check:

   Date & time + time zone = TIMESTAMP WITH TIME ZONE [OK]

Hint: Use TIMESTAMP WITH TIME ZONE for date, time, and zone [OK]

Common Mistakes:

• Using TIMESTAMP without time zone when zone is needed
• Trying to add time zone to DATE or TIME types
• Incorrect syntax like DATE WITH TIME ZONE

3. Given the table events(event_time TIMESTAMP) and the query:
SELECT event_time::DATE FROM events WHERE event_time > '2024-01-01 12:00:00';
What will be the output type of the query?

medium

A. TIMESTAMP values

B. TIME values

C. DATE values

D. TEXT values

Solution

1. Step 1: Understand the cast operation

   The ::DATE casts the TIMESTAMP to DATE, removing time part.

2. Step 2: Analyze the query output

   The SELECT returns only the date part of event_time, so output type is DATE.

3. Final Answer:

   DATE values -> Option C

4. Quick Check:

   CAST TIMESTAMP to DATE = DATE output [OK]

Hint: Casting TIMESTAMP::DATE returns only date part [OK]

Common Mistakes:

• Assuming output remains TIMESTAMP
• Thinking output is TIME only
• Confusing cast with string conversion

4. You wrote this query:
SELECT event_time + '1 day' FROM events;
But it gives an error. What is the likely cause?

medium

A. The string '1 day' must be cast to INTERVAL before adding

B. You cannot add intervals to TIMESTAMP in PostgreSQL

C. You must use DATE type for adding days

D. The column event_time is not a date or timestamp

Solution

1. Step 1: Understand adding intervals to timestamps

   In PostgreSQL, you add intervals to timestamps, but the interval must be of type INTERVAL.

2. Step 2: Identify the error cause

   The string '1 day' is text and must be cast to INTERVAL using '1 day'::INTERVAL or INTERVAL '1 day'.

3. Final Answer:

   The string '1 day' must be cast to INTERVAL before adding -> Option A

4. Quick Check:

   Add INTERVAL to TIMESTAMP, cast string first [OK]

Hint: Cast '1 day' to INTERVAL before adding to timestamp [OK]

Common Mistakes:

• Adding string directly without casting
• Assuming TIMESTAMP + string works
• Using DATE type incorrectly

5. You want to store event start times in UTC but display them in users' local time zones. Which PostgreSQL data type and function combination is best to store and convert these times?

hard

A. Store as TIMESTAMP and use AT TIME ZONE to convert

B. Store as TIMESTAMP WITH TIME ZONE and use AT TIME ZONE to convert

C. Store as TIME and use SET TIMEZONE to convert

D. Store as DATE and use TIMEZONE() to convert

Solution

1. Step 1: Choose the correct storage type

   TIMESTAMP WITH TIME ZONE stores the exact moment in time with zone info, ideal for UTC storage.

2. Step 2: Use conversion function

   AT TIME ZONE converts stored UTC times to users' local time zones for display.

3. Final Answer:

   Store as TIMESTAMP WITH TIME ZONE and use AT TIME ZONE to convert -> Option B

4. Quick Check:

   Use TIMESTAMP WITH TIME ZONE + AT TIME ZONE for zone conversion [OK]

Hint: Use TIMESTAMP WITH TIME ZONE + AT TIME ZONE for conversions [OK]

Common Mistakes:

• Storing as TIMESTAMP without time zone loses zone info
• Using DATE or TIME types which lack full timestamp info
• Confusing SET TIMEZONE session setting with conversion