Fix Notion Rollup Date Aggregation Returns Wrong Time Zone Output

When you use a Rollup property in Notion to aggregate dates from linked database entries, the output may show a time that is several hours off from what you expect. This often appears as a difference of exactly 4, 5, or 8 hours, depending on your region. The root cause is that Notion stores all date-time values in UTC and the Rollup aggregation does not convert them back to your local time zone before displaying the result. This article explains why this discrepancy occurs and provides clear steps to correct the time zone output in your rollup formulas.

Why Notion Rollup Date Aggregation Returns UTC Instead of Local Time

Notion stores all date-time values in Coordinated Universal Time (UTC). When you create a Date property in a database, Notion converts the local time you enter into UTC for storage. The display on the page uses your browser or app time zone settings, so you see the correct local time. However, when you use a Rollup property to aggregate date values — for example, to find the earliest or latest date among linked entries — the Rollup function performs its calculation on the underlying UTC values. The result is then displayed as a UTC timestamp without conversion back to your local time zone. This behavior is by design; Rollup returns the raw computed value. The same issue occurs with the formula functions prop("Rollup") when you try to manipulate the aggregated date.

The Difference Between Display and Storage

A Date property on a Notion page shows the time in your local zone because Notion applies a time zone conversion at render time. A Rollup property that aggregates dates bypasses that conversion layer. The Rollup output is the exact UTC value from the calculation. For example, if you have two linked events with start times of 10:00 AM and 2:00 PM Eastern Time (UTC-5), Notion stores them as 15:00 UTC and 19:00 UTC. The Rollup showing the earliest date will output 15:00 UTC, not 10:00 AM ET. This 5-hour difference is the root of the confusion.

Steps to Adjust the Time Zone in a Rollup Date Output

Because Rollup cannot be configured to output in a specific time zone, you must create a Formula property that takes the Rollup value and shifts it to your local time. Follow these steps carefully.

1. Identify the rollup property and its aggregation type
   Open your Notion database and locate the Rollup property that is returning the wrong time. Note the aggregation function used — Earliest Date, Latest Date, or Count. Only date-based aggregations produce a date output that can be shifted.
2. Create a new Formula property
   In the database, click the + button in the last column header. Select Formula as the property type. Name it something like “Corrected Date” or “Local Rollup”.
3. Write the formula to shift the UTC time
   In the formula editor, use the dateAdd or dateSubtract function to adjust by your time zone offset. For example, for Eastern Time (UTC-5, or UTC-4 during daylight saving), use:
   dateAdd(prop("Rollup"), 5, "hours")
   If you are east of UTC, use dateSubtract. Replace “Rollup” with the exact name of your rollup property. Replace the number with your offset in hours.
4. Handle daylight saving time automatically (optional)
   Notion formulas do not have a built-in time zone database. To account for DST dynamically, you can use a conditional formula that checks the month. For example, for US Eastern Time:
   if(month(prop("Rollup")) >= 3 && month(prop("Rollup")) <= 10, dateAdd(prop("Rollup"), 4, "hours"), dateAdd(prop("Rollup"), 5, "hours"))
   This adjusts between EDT (UTC-4) and EST (UTC-5). Adjust the month range and offset values for your region.
5. Format the output as a date with time
   By default, a formula that returns a date will display in the format defined in the Formula property settings. Click the Formula property header, select Edit property, then choose Date format. Select a format that includes the time, such as "MMM D, YYYY h:mm A". This ensures you see both date and time in the corrected time zone.
6. Test with a known time
   Create a test entry with a Date property set to a time you know, such as 12:00 PM local time. Link it to another entry that contains the rollup. Check the corrected formula output. It should now show 12:00 PM in your local zone instead of the UTC equivalent.

If Notion Rollup Still Shows Wrong Time After Formula Adjustment

Rollup aggregation type is Count or Count Values

If your Rollup uses Count or Count Values, the output is a number, not a date. The formula shift method will not work because you cannot add hours to a number. In this case, the Rollup does not produce a date output, so there is no time zone issue. The count is correct as a numeric value.

Formula returns an error after adding hours

If the Rollup aggregation returns a date that is null for some rows, the dateAdd function will return an error. Wrap the formula in an if statement to check for empty values first:
if(empty(prop("Rollup")), "", dateAdd(prop("Rollup"), 5, "hours"))
This prevents errors for entries without linked data.

Time zone offset changes during the year

The static offset method does not automatically switch between standard and daylight saving time. If you need year-round accuracy without manual updates, use the conditional formula described in Step 4. Alternatively, accept a fixed offset and manually adjust the formula twice a year when DST changes.

Rollup Date Handling Options: Formula vs Manual Adjustment

Item	Formula with dateAdd/dateSubtract	Manual Date Property Entry
Time zone correction	Adjusts UTC to local time automatically	No correction needed if entered in local time
Automation	Updates dynamically when rollup value changes	Requires manual re-entry if source dates change
DST handling	Possible with conditional formula, but complex	Not applicable — manual entry uses your current zone
Complexity	Requires formula writing and testing	Simple but time-consuming for many entries
Error prone	Low if offset is correct	High — easy to forget to update

This article walked through why Notion Rollup date aggregation returns UTC instead of your local time and how to fix it using a Formula property with dateAdd or dateSubtract. You can now correct the time zone output for any rollup that returns a date value. To avoid manual DST adjustments, implement the conditional month-check formula. For databases that require precise local time in rollups, consider using a separate Date property that you update manually instead of relying on rollup aggregation.