Timezones and locales
  • 24 Oct 2022
  • 5 Minutes to read
  • Dark
    Light

Timezones and locales

  • Dark
    Light

This article will cover how to work with and troubleshoot timezones, and is part of a guided course which you can view here.

Options for displaying dates

All dates are stored in Airtable in Greenwich Mean Time, or GMT. But, how you choose for them to display in your base is a field-level setting that will affect all collaborators. You can have dates display either:

  1. In collaborators' local time, so the datetime will appear different for viewers in different timezones, adjusted from GMT
  2. As the same for everyone, if you choose to have the field configured as a GMT field by switching on the "Use the same timezone for all collaborators" toggle shown below, in the field's customization menu.

Here are a few facts related to this:

  • There is no workspace, base, table, or user-wide timezone setting in Airtable.
  • Any formatted date has the potential to be set to GMT time - or not.
  • Any formatted date can be specified to show a specific timezone.

What this means is that collaborators working together in the same base can, and will, see different dates and times unless a specific timezone has been specified, or, using GMT time for all collaborators has been toggled on (again, on a field-by-field basis).

Setting a timezone

The SET_TIMEZONE()function will allow you to set the timezone for the data from a date type field. This article will cover its use and is part of a guided course which you can view here.

This is written in the form SET_TIMEZONE(datetime, 'timezone identifier'), in which the format specifier can be something like 'America/Chicago', 'Europe/Oslo', or 'Pacific/Marquesas'.

your title goes here

For a full list of supported timezone identifiers, see this article.

Whenever you need to set a timezone, you'll need to use this function in combination with DATETIME_FORMAT(). You'll first write the DATETIME_FORMAT function, and then wrap that function with SET_TIMEZONE().

For example, if a date field is configured to not use GMT time; therefore, the date will be shown in your local timezone (CST). Using the combination of SET_TIMEZONE()and DATETIME_FORMAT(), you can convert what's shown in the date field to Los Angeles time.

DATETIME_FORMAT(
  SET_TIMEZONE(
    Date, 'America/Los_Angeles'),
  'M/D/Y h:mm A'
)

Here's the result of this formula:

360099323974timezone-1.jpg

There's just one problem - the result of this formula is not a formatted date that's readable by Airtable. Remember that DATETIME_FORMAT() converts datetimes into strings. We'll need to use DATETIME_PARSE() to transform this string into a readable date. Below, the {Set Timezone} field is referenced instead of using the original formula above to keep the formula simplified.

DATETIME_PARSE(
  {Set Timezone},
  'M/D/YYYY h:mm A'
)

Here's the result of this second formula:

360101546733timezone-2.gif

The output of this formula is now a formatted date. Now that we've gone over the separate parts of this formula, let's bring it all together into a single formula:

DATETIME_PARSE(
   DATETIME_FORMAT(
      SET_TIMEZONE(
         Date, 'America/Los_Angeles'
      ),
   'M/D/Y h:mm A'),
'M/D/YYYY h:mm A'
)

1500000448202timezone-3.gif

Notice that the option to "Use the same timezone (GMT) for all collaborators" is toggled on in the field formatting settings. This is needed to display the correct time.

Setting a locale

Now that we've translated a local time to a specified timezone, let's look at how to further transform that into a locale (a specific language or region).

The SET_LOCALE()function takes a given datetime input and formats it to match a particular locale. This function is written in the form SET_LOCALE(datetime, 'locale modifier'), in which the locale modifier can be something like 'en-nz' (New Zealand English), 'tzm' (Amazigh/Berber), or 'zh-tw' (Traditional Chinese).

Locale modifiers can change a number of different aspects of a datetime, including:

  • Numerical digits: for certain locales not using West Arabic numerical digits, numerical digits will be converted, e.g. for 'ar' (Arabic), 1 => ٢.
  • Script directionality: for locales using scripts that are written right-to-left, e.g. 'he' (Hebrew), the datetime will change direction accordingly.
  • Month and weekday names : month/weekday names will be changed to reflect the locale's language, e.g. for 'es' (Spanish), Wednesday => Miércoles.
  • Long date format : Long datetimes will be formatted according to the preferred format of the locale, e.g. for 'en-gb' (British English), 'MMMM D, YYYY h:mm A' => 'D MMMM YYYY HH:mm'.

For a full list of all locales, see this support article.
As an example, we'll translate the datetime into Spanish. Here's the original formula:

DATETIME_PARSE(
   DATETIME_FORMAT(
      SET_TIMEZONE(
         Date, 'America/Los_Angeles'
      ),
   'M/D/Y h:mm A'),
'M/D/YYYY h:mm A'
)

And here is that same formula with the added locale function:

DATETIME_FORMAT(
    SET_LOCALE(
        DATETIME_PARSE(
            DATETIME_FORMAT(
               SET_TIMEZONE(
                  Date, 'America/Los_Angeles'
               ),
            'M/D/Y h:mm A'),
         'M/D/YYYY h:mm A'
         ), 
    'ES'), 
'LLLL'
)

360101546693timezone-4.jpg

A different approach

There's another way to specify timezones that can, at times, be a more simple approach. We've already reviewed the use of DATEADD();now we'll look at how to use this function alongside timezones.

Remember that the structure of that function is:

DATEADD  (Date, #,  'units'  )  

Or:

DATEADD  ({Date Field},  5  ,  'days'  ) 

Since every timezone in the world is offset a certain number of hours from GMT time, we can easily specify a timezone without using the SET_TIMEZONE() function. Here are a few cities listed with the difference, in hours, from GMT:

  • New York: -4
  • Chicago: -5
  • San Francisco: -7
  • London: +1

1500000456641timezone-6.jpg

The formula below will convert the GMT time to the local timezones, which are each specified by how many hours they are offset from GMT.

DATEADD  ({GMT Date},{GMT Diff}, 'hours'  )

1500000448182timezone-7.jpg

This approach can be helpful if a date needs to be specified in GMT time, but collaborators in other regions need to see that time translated to their local timezone.

Troubleshooting timezone issues

While formula functions help take a lot of trouble out of timezones, the nature of time differences can still be confusing from time to time. When something doesn’t work out the way you expected, you can often resolve the issue if you know how to troubleshoot—so let’s give it a try!

Consider the following formula:

IS_SAME(NOW (),{Start Day & Time },'day ')

Something’s not working quite right, but what could it be? Here’s the issue in detail:

You just started using IS_SAME() to match up dates that are the same. In your table, all tasks that have today's date are the same. However, some tasks have a timestamp occurring after 7:00 PM EST and those records are failing to match as TRUE (same) when compared with TODAY() using IS_SAME(). If you change the timestamp to be earlier than 7:00 PM EST everything works fine. Is it some fixed time zone issue with the TODAY() function?

For proper reference, these are the results you’re getting with the formula in question:

1500000448162timezone-8.jpg

We can assume that NOW() is correctly producing the same date as shown in the {Start Day & Time} field. Because NOW() is equal to 4/10/2020, the formula should produce a 1 for every record shown here.

Have you discovered what the problem is?

GMT time is toggled ON in the date field settings!
🎉 Correct! The date field is displaying values in local time, while the NOW() formula is producing a date in GMT time, which for some of the records falls on the next day. Remember that all dates in Airtable are stored as GMT.
GMT time is toggled OFF in the date field settings!
🤔 Sorry, that's not the correct answer...


Formula Foundations

This article is part of a guided course that helps you learn how to use Airtable formulas.

View Course



Was this article helpful?