Why Notion Formula Output Shows Different Time Zone From Source Date

You have a date property in a Notion database that shows the correct local time, but a formula that references that date displays a different time zone offset. This discrepancy causes confusion when you need consistent timestamps for reports, deadlines, or event scheduling. The root cause is how Notion internally stores and then formats dates when a formula processes them. This article explains why the time zone shift occurs and provides the exact formula adjustments to keep your output time zone consistent with the source date.

Why Notion Formulas Display a Different Time Zone

Notion stores all date values internally as UTC timestamps. When you create a date property and enter a time, Notion converts that local time to UTC before saving it. When a formula reads that date property, it retrieves the UTC value and then applies its own formatting rules. By default, Notion formulas output dates in the UTC time zone unless you explicitly tell the formula to use a different time zone. This is why the source date property shows your local time but the formula shows a shifted time.

The source date property uses your workspace time zone setting or your browser’s local time zone to display the date. Formulas do not inherit this setting automatically. The formatDate() function in Notion accepts an optional time zone parameter. If you omit that parameter, the formula defaults to UTC. The result is a time that can be several hours ahead or behind the original entry.

How Notion Handles Time Zones Internally

When you type a date in a date property, Notion captures the local time from your system clock. It then converts that time to UTC using the offset of your current time zone. For example, if you are in New York (Eastern Daylight Time, UTC-4) and enter 3:00 PM, Notion stores 7:00 PM UTC. The date property displays 3:00 PM because it knows your workspace time zone. The formula, however, sees 7:00 PM UTC and outputs that value unless you intervene.

The Role of the Workspace Time Zone Setting

You can set a default time zone for your workspace in Settings & Members > Settings > Workspace. This setting controls how new date properties display their values. It does not change how existing formulas format their output. Changing the workspace time zone after dates have been entered will update the display of those date properties, but formulas will still need explicit time zone instructions to match.

Steps to Fix the Time Zone Mismatch in a Formula

You can correct the time zone offset by adding the time zone parameter to the formatDate() function in your formula. Follow these steps to update an existing formula.

1. Open the database property editor
   Navigate to the database that contains the formula property. Click the property name at the top of the column, then select “Edit property” from the dropdown menu.
2. Locate the formula field
   In the property editor, find the Formula property type. Click the “Edit formula” button to open the formula editor window.
3. Add the time zone parameter to formatDate()
   If your current formula uses formatDate(prop("Date"), "MMM D, YYYY h:mm A"), change it to formatDate(prop("Date"), "MMM D, YYYY h:mm A", "America/New_York"). Replace "America/New_York" with your IANA time zone string. Common values are "America/Chicago", "America/Denver", "America/Los_Angeles", "Europe/London", "Europe/Berlin", "Asia/Tokyo", and "Australia/Sydney".
4. Test the formula output
   Click “Save” and check the formula column. The displayed time should now match the source date property. If it does not, verify that the time zone string is correct and that the source date property includes a time component.
5. Repeat for all affected formulas
   Apply the same time zone parameter to every formula that references a date property. Each formula that lacks the parameter will continue to display UTC.

Using fromTimestamp() as an Alternative

If you prefer not to use formatDate(), you can convert the date to a Unix timestamp and then back to a date with an explicit time zone. This method is useful when you need to perform arithmetic on dates before formatting.

1. Convert the source date to a number
   Use toNumber(prop("Date")) to get the Unix timestamp of the source date. This value is always in UTC.
2. Add the time zone offset
   Add or subtract the offset for your time zone. For Eastern Daylight Time (UTC-4), add -14400 seconds (4 hours 3600). For Eastern Standard Time (UTC-5), add -18000.
3. Convert back to a formatted date
   Use formatDate(fromTimestamp(adjustedTimestamp), "MMM D, YYYY h:mm A"). This forces the formula to treat the adjusted timestamp as local time.

If Notion Still Shows the Wrong Time Zone After the Fix

Formula Still Outputs UTC Even After Adding the Time Zone Parameter

This usually happens when the time zone string is misspelled or not recognized by Notion. Double-check the IANA time zone string. Use a known valid string such as "America/New_York". If the string is invalid, Notion silently falls back to UTC. The formatDate() function does not return an error for an invalid time zone; it just ignores it.

Source Date Property Does Not Include a Time

If the source date property is set to “Date only” (no time component), Notion assumes midnight UTC for that date. The formula will display midnight in the specified time zone, which can appear as the previous day in some time zones. To fix this, change the date property to include a time. Open the date property settings and enable “Include a time.” Then re-enter the date with the correct local time.

Formula Output Changes When Viewed on a Different Device

Notion formulas that use formatDate() with a time zone parameter are evaluated on the server. The output is the same for all viewers regardless of their local time zone. If you see different times on different devices, the formula is likely missing the time zone parameter, and each browser is applying its own local offset. Add the explicit time zone string to the formula to make the output consistent.

Notion Formula Date Functions: Behavior With and Without Time Zone

Function	Without Time Zone Parameter	With Time Zone Parameter
formatDate()	Outputs date in UTC	Outputs date in the specified IANA time zone
dateAdd()	Adds days/hours in UTC	Adds days/hours in the specified time zone (daylight saving aware)
dateSubtract()	Subtracts in UTC	Subtracts in the specified time zone
now()	Returns current UTC timestamp	Not applicable — now() does not accept a time zone parameter
fromTimestamp()	Converts UTC timestamp to a date object	Does not accept a time zone parameter — use formatDate() on the result

You can now align the time zone of any formula output with the source date property. The key step is adding the correct IANA time zone string to every formatDate() call. For formulas that perform date math, use dateAdd() or dateSubtract() with the time zone parameter to keep daylight saving adjustments accurate. As an advanced tip, create a formula property that stores the time zone string as a variable using lets() so you only need to update the string in one place if your time zone changes.