How to Build Notion Formula for Time Zone Aware Meeting Scheduler

You want to create a meeting scheduler in Notion that shows times in the correct time zone for each participant. Notion stores dates in UTC internally but displays them based on your browser or app time zone. This behavior can cause confusion when you share a database with people in different time zones. This article explains how to build a formula that converts a stored meeting time into a target time zone and displays it clearly in a Notion database.

You will learn how to use Notion’s date functions, handle UTC offsets, and create a formula that outputs a readable time string. The solution uses a combination of dateAdd, formatDate, and if statements. By the end, you will have a working scheduler that shows meeting times adjusted for any time zone you specify.

How Notion Stores Dates and Why Time Zones Matter

Notion stores every date property internally as a UTC timestamp. When you view a date in the app or browser, Notion converts it to your local time zone. This conversion is automatic and invisible. The problem appears when you share a database with team members in different time zones. Each person sees the meeting time converted to their own local time, which may not match the intended meeting time for the organizer.

For example, you enter a meeting at 3:00 PM in New York (UTC-5). A colleague in London (UTC+0) sees the same meeting at 8:00 PM. If you want the meeting to display at a fixed time regardless of the viewer’s location, you need a formula that overrides the automatic conversion. The formula must take the stored UTC date, apply a specific offset, and output a string that does not change based on who looks at it.

What a Time Zone Aware Formula Does

The formula reads the date property, adds or subtracts the number of hours for a target time zone, and then formats the result as a plain text string. Because the output is text, Notion does not convert it again. The displayed time remains the same for every viewer. This approach works for scheduling meetings where the time zone is fixed, such as a recurring team standup at 10:00 AM Eastern Time.

Steps to Build the Time Zone Conversion Formula

The following steps assume you have a Notion database with a Date property named Meeting Date. You will create a Formula property that converts that date to a target time zone and shows only the time. The example targets Eastern Time (UTC-5) during standard time. Adjust the offset for your own time zone.

1. Create the Date property
   In your Notion database, add a new property of type Date. Name it Meeting Date. Enter a test date and time, for example December 15, 2025 at 3:00 PM. Notion stores this as UTC internally. If you are in New York (UTC-5), the stored UTC value is 8:00 PM UTC.
2. Add a Formula property
   Add another property of type Formula. Name it Meeting Time ET. This property will hold the formula that converts the UTC date to Eastern Time.
3. Write the base conversion formula
   Click into the formula field and enter the following code:
   formatDate(dateAdd(prop("Meeting Date"), -5, "hours"), "h:mm A")
   This formula uses dateAdd to subtract 5 hours from the stored UTC date, converting it to Eastern Standard Time. Then formatDate extracts only the time in 12-hour format with AM/PM.
4. Test the formula with a known time
   If you entered a meeting at 3:00 PM ET on December 15, 2025, the formula should output 3:00 PM. If you are in a different time zone, temporarily change your Notion settings to UTC to verify the raw input. The formula output should be a text string that does not change when viewed by other users.
5. Handle daylight saving time
   Notion formulas do not have a built-in daylight saving time function. To handle DST, you need to check the date and apply a different offset. Use the if function with the month or week range. For example, Eastern Daylight Time (UTC-4) applies from the second Sunday in March to the first Sunday in November. A simplified version:
   if(month(prop("Meeting Date")) >= 3 and month(prop("Meeting Date")) <= 10, formatDate(dateAdd(prop("Meeting Date"), -4, "hours"), "h:mm A"), formatDate(dateAdd(prop("Meeting Date"), -5, "hours"), "h:mm A"))
   This checks if the month is between March and October. Adjust the month boundaries for your region.
6. Display the date and time together
   If you want to show both the date and the converted time, change the format string to "MMM D, YYYY h:mm A". For example:
   formatDate(dateAdd(prop("Meeting Date"), -5, "hours"), "MMM D, YYYY h:mm A")
   This outputs something like Dec 15, 2025 3:00 PM.

Alternative: Use a Select Property for Time Zone

If you need to support multiple time zones in the same database, add a Select property named Time Zone with options like EST, PST, and GMT. Then use a nested if statement in the formula to pick the correct offset. Example structure:

if(prop("Time Zone") == "EST", formatDate(dateAdd(prop("Meeting Date"), -5, "hours"), "h:mm A"), if(prop("Time Zone") == "PST", formatDate(dateAdd(prop("Meeting Date"), -8, "hours"), "h:mm A"), formatDate(dateAdd(prop("Meeting Date"), 0, "hours"), "h:mm A")))

This approach lets each row specify its own target time zone. The formula reads the selection and applies the corresponding offset.

Common Mistakes and Limitations

Even with a correct formula, you may encounter issues. The following are the most frequent problems and how to solve them.

Formula Output Shows UTC Time Instead of Converted Time

If the formula outputs the original UTC time, check that you are using dateAdd correctly. The first argument must be the Date property, not a text string. Also verify that the offset sign is correct. For time zones east of UTC (like Europe), you add hours. For west (like Americas), you subtract hours.

Daylight Saving Time Causes One-Hour Error Twice a Year

The formula above uses a month range for DST. This is not precise for all regions. For example, the United States changes clocks on the second Sunday in March and the first Sunday in November. To get exact DST boundaries, you would need a more complex formula that calculates the day of week. In practice, the month range works for most business scheduling needs. If you require exact DST transitions, consider using an external tool or a lookup table.

Viewing the Database in a Different Time Zone Changes the Date Property

Remember that the original Meeting Date property is still subject to Notion's automatic time zone conversion. If you open the database on a device set to Pacific Time, the raw date property will show a different time than what you entered. The formula property, because it outputs text, remains constant. Always use the formula output for scheduling decisions, not the raw date property.

Formula Options Compared: Text Output vs Date Output

Item	Text Formula (Recommended)	Date Formula (Not Recommended)
Output type	Plain text string	Date object
Time zone stability	Fixed — does not change per viewer	Changes based on viewer's local time zone
Sorting	Alphabetical, not chronological	Chronological
Filtering	Text-based only	Date range filters work
Use case	Displaying meeting times in a fixed time zone	If you need sorting and filtering by the original UTC time

For most scheduling needs, the text formula is the better choice. It ensures every participant sees the same time regardless of their location. If you need sorting by meeting time, keep the original Date property for sorting and add a separate text formula for display.

You can now build a Notion formula that converts UTC dates to any target time zone and displays the time as a fixed string. Start by creating a simple formula with a static offset, then add DST handling and a time zone selector if needed. For advanced scheduling with multiple time zones, consider using a Select property to let each row specify its own offset. The key is to output text so Notion never re-converts the value.