The question: why do my times look wrong?

You enter a date and time and the value appears hours off in another field. Or a view filtered for Today excludes late night entries. Time zones and formatting choices can cause confusing results if you are not explicit.

Key facts

There is no global time zone setting for a base or user
A date with time can be stored and displayed in different zones
The "Use the same time zone for all collaborators (UTC)" toggle affects storage and display
SET_TIMEZONE() only affects display—it doesn't change the stored value
You must use DATETIME_FORMAT() after SET_TIMEZONE() to see the change

Implication: treat storage and display separately and make the time zone explicit in formulas and formatting.

How SET_TIMEZONE works

SET_TIMEZONE() converts a date/time value to a specific time zone for display purposes. It doesn't modify the underlying stored value.

Important: SET_TIMEZONE() alone won't change what you see. You must combine it with DATETIME_FORMAT():

SET_TIMEZONE({Date Field}, 'America/New_York')
// This returns a date object, but won't display differently

DATETIME_FORMAT(
  SET_TIMEZONE({Date Field}, 'America/New_York'),
  'M/DD/YYYY h:mm A'
)
// This displays the date in the specified time zone

Display a date in a specific time zone

Wrap the source date with SET_TIMEZONE and then format it.

DATETIME_FORMAT(
  SET_TIMEZONE({Start Date}, 'America/Los_Angeles'),
  'MM/DD/YY HH:mm'
)

Common example for created time:

DATETIME_FORMAT(
  SET_TIMEZONE(CREATED_TIME(), 'America/Chicago'),
  'M/DD/YYYY h:mm A'
)

Tip: do not expect SET_TIMEZONE(date) alone to change the visible value. You must format the result for display.

Common time zone identifiers

Use IANA time zone names (Area/City format) with SET_TIMEZONE():

United States

'America/New_York'      // Eastern Time
'America/Chicago'       // Central Time
'America/Denver'        // Mountain Time
'America/Los_Angeles'   // Pacific Time
'America/Phoenix'       // Mountain Time (no DST)
'America/Anchorage'     // Alaska Time
'America/Honolulu'      // Hawaii Time

Other regions

'Europe/London'         // UK Time
'Europe/Paris'          // Central European Time
'Asia/Tokyo'            // Japan Time
'Asia/Shanghai'         // China Time
'Australia/Sydney'      // Australian Eastern Time
'UTC'                   // Coordinated Universal Time

Choose between local time and UTC

Option 1: Local time storage

Turn the UTC toggle off on date fields with time
Each user sees times in their local time zone
Use SET_TIMEZONE for targeted display when needed

Pros: Intuitive for users in the same time zone
Cons: Can cause confusion with remote teams, filters may behave unexpectedly

Option 2: UTC storage (recommended)

Turn the UTC toggle on for consistent storage and comparison
Store all dates in UTC
Format to local time only in presentation fields

Pros: Consistent across all users, reliable filters and comparisons
Cons: Requires explicit formatting for user-friendly display

Recommendation: prefer UTC for storage and comparisons and format to local only where users read the value.

Practical examples

Show current time in multiple time zones

Create separate formula fields for each time zone:

New York time:

DATETIME_FORMAT(
  SET_TIMEZONE(NOW(), 'America/New_York'),
  'M/DD/YYYY h:mm A'
)

London time:

DATETIME_FORMAT(
  SET_TIMEZONE(NOW(), 'Europe/London'),
  'M/DD/YYYY h:mm A'
)

Convert stored UTC to user's local time

If your date field stores UTC (UTC toggle enabled):

DATETIME_FORMAT(
  SET_TIMEZONE({Event Date}, 'America/Los_Angeles'),
  'ddd, MMM D, YYYY h:mm A'
)

Show time zone abbreviation

You can't directly get time zone abbreviations (EST, PST, etc.) from Airtable formulas, but you can add them manually:

DATETIME_FORMAT(
  SET_TIMEZONE({Date}, 'America/New_York'),
  'M/DD/YYYY h:mm A'
) & " EST"

Filters that always work

Filtering on a formatted string can break since the field is no longer a true date. Keep a pure date field for filters and build a separate formatted field for display.

Pattern:

Field A: the real date or created time (raw date field)
Field B (formula): formatting and time zone conversion for display
Views: filter on Field A, show Field B to users

Example setup:

{Event Date} - Date & time field (UTC enabled)
{Event Date Display} - Formula field:

DATETIME_FORMAT(
  SET_TIMEZONE({Event Date}, 'America/New_York'),
  'M/DD/YYYY h:mm A'
)

In your view: Filter by {Event Date}, display {Event Date Display}.

Troubleshooting common issues

Times appear hours off

Problem: Times show incorrectly after conversion.

Solution: Check if your source field has UTC enabled. If it does, the stored value is already in UTC. If it doesn't, Airtable may be interpreting it as local time.

"Today" filter excludes records

Problem: Records created late at night don't appear in "Today" filter.

Solution: This happens when dates are stored in UTC but filtered in local time. Enable UTC on the date field, or create a separate date-only field for filtering.

SET_TIMEZONE doesn't seem to work

Problem: Using SET_TIMEZONE() but seeing no change.

Solution: Remember to wrap it in DATETIME_FORMAT(). SET_TIMEZONE() alone returns a date object that looks the same when displayed.

Inconsistent times across users

Problem: Different users see different times for the same record.

Solution: Enable UTC on the date field to store consistently, then format to local time in formula fields for display.

Quick reference

Goal	Reliable approach
Show date in a specific zone	`DATETIME_FORMAT(SET_TIMEZONE(date, 'Area/City'), 'format')`
Store and compare consistently	Enable UTC toggle and compare raw dates
Human friendly display	Keep a separate formatted field for UI
Filter by date	Filter on raw date field, display formatted field
Multiple time zones	Create separate formula fields for each time zone

Common formats

'MM/DD/YY HH:mm'        // 04/05/25 18:30
'M/DD/YYYY h:mm A'      // 4/5/2025 6:30 PM
'ddd, MMM D, YYYY'      // Sat, Apr 5, 2025
'YYYY-MM-DD HH:mm:ss'  // 2025-04-05 18:30:00
'MMM D, YYYY'           // Apr 5, 2025

Best practices

1. Store in UTC, display in local

Enable UTC on date fields, then format to local time zones only in formula fields for user display.

2. Separate storage and display

Keep raw date fields for filtering and calculations. Create formula fields for formatted, time-zone-converted display.

3. Be explicit about time zones

Always specify the time zone in SET_TIMEZONE() rather than relying on defaults. This makes your formulas predictable and maintainable.

4. Document your time zone choices

If your base uses a specific time zone for business logic, document it clearly so team members understand the conventions.

5. Test with edge cases

Test your time zone conversions with:

Dates near daylight saving time transitions
Times around midnight (especially for "Today" filters)
Users in different time zones

Opinionated take

Storing dates in UTC and formatting at the edge simplifies filters, rollups, and automations. Use SET_TIMEZONE only where humans read the value. This approach ensures consistency across your base while still providing user-friendly displays.

Airtable Time Zones: How to Control Display and Calculations