New Beta: More time zone formatting options for datetime fields

[Elena_Jia]

Hi everyone!

Update 2022/11/02 - The new time zone formatting options for date time fields are now generally available!

We’re excited to announce a new beta feature that allows you to specify a display time zone of your choice on date fields that include time and formula fields that output a datetime value. Once you specify a time zone for a field, this time zone will be visible and used for all collaborators.

We’ve heard your feedback that time and time zones can be tricky to manage, and we hope that being able to choose from a broader list of global time zones can make collaborating across time zones much easier and clearer for you and your teams.

You’ll only be able to use these field-level time zone settings in your base if you’ve signed up for the beta and you can sign up for the beta via this form. As you’re trying out the feature, please submit any feedback/issues here.

Read on for more information!

For datetime fields, you can access this feature by going to the field configuration menu and toggling on both “Include time” and “Use the same time zone for all collaborators”. Setting custom time zones is only supported for fields that include time.

For formula fields, you can access this feature by going to your field configuration menu and navigating to the Formatting tab.

This feature is still in development, so there are some known gaps and aspects may be subject to breaking changes. Please keep this in mind and be judicious on how you use this beta feature in your bases.

Current known gaps include:

• Syncs involving new time zones are currently based on the displayed time. They will be based on the underlying timestamp instead. [update on 9/9/2022 - syncing a date field value from one base to another is now based on the underlying timestamp, for example 8/1/2022 5:00 pm GMT will be synced to 8/1/2022 10:00 am PDT]
• Setting display time zones on mobile is not yet supported.

Please don’t hesitate to reply in this thread with any questions, and thank you in advance for your time and consideration.

[John_inNJ]

just to clarify. I won’t be modifying the date time fields, airtable will, right? In other words, this is a change Airtable will implement on a specific day, without action from me, that will modify all the date/time fields.

[Elena_Jia]

@John_inNJ I see - without any action on your side, any existing date time fields won’t be updated and no cell value will change either. This feature simply allows users to configure date time fields with additional time zones if that’s desired.

[aleaja]

Glad to see these new datetime features in the pipeline! They’ll be super useful.

That said, I’m noticing an error in the API when creating records with datetime fields (via pyairtable). The datetime appears to be formatted correctly, but returns an INVALID_VALUE_FOR_COLUMN error:

Error: {
    'type': 'INVALID_VALUE_FOR_COLUMN',
    'message': 'Cannot parse date value "2022-10-03T12:40:00.000+00:00Z" for field Scheduled start time'
}

Do you know why this might be? Is this a known issue?

[ScottWorld]

That is not valid ISO 8601 formatting for the date & time. It should look something like this:

2022-09-20T16:32:11+00:00

Here are the 3 acceptable ways of formatting date & time with ISO 8601 formatting:

2022-09-20T16:32:11+00:00

2022-09-20T16:32:11Z

20220920T163211Z

[NikolinaGaraca]

That is great news indeed, @Elena_Jia ! I’d like to second what Scott wrote–we heavily use Date fields and formula fields with dates only (no times), and they still sometimes cause confusion due to timezone differences. It would be great to see this update in fields that solely have dates.

[Karlstens]

Yup, I’ve been wanting local date only fields for many years now. Caused me much grief when first learning the product and how to code - lucky Airtable has great support staff who were able to help me out.

[Karlstens]

Good morning @Elena_Jia

We’re finding the inability to apply a timezone to a Date Only fields a problematic - in our current scenario, we have a Time Line interface and Time Line views tied to Date Only fields, and we just spotted that the Time Line acts on GMT, and not our local time.

Problem being, we don’t know what ramifications we’ll get if we enable “Date Only” fields to include Times, just so we can fix the Time Zone issue. The date fields have Automations tied to them and are exporting their details via JSON… etc.

It confuses the users we’re training, when we have Date Only structure, that’s showing time time 00:00 and 23:59 - we’re really just needing to set the Time Zone on Date Only.

EDIT: Oh, and most importantly, users are working off a Timeline at 8am that shows them the date is still yesterday - that then changes to the correct day at what-ever the offset time is. It’s most troublesome.

[ScottWorld]

Everyone, be sure to also leave your feedback at the form below, in addition to this thread.

Airtable

Share feature feedback - Airtable

Fill out the "Share feature feedback" form quickly and securely on Airtable.

[Robert_Phung]

Thank you all for your feedback so far!

Just a quick update for bases using the beta with formulas- On October 31, we’ll be making changes to how to how the IF formula handles custom time zones. Formulas that evaluate field directly such as IF({dateTimeInLosAngeles}, "true", "false") will output true rather than #ERROR! when the cell contains a value.

[Partyborn]

With the new timezone information set, this means we no longer need SET_TIMEZONE(Start, 'Europe/Berlin') in formulars that use DATETIME_FORMAT()?

e.g. I need this when I want to correctly display the week number in german: DATETIME_FORMAT(SET_TIMEZONE(Start, 'Europe/Berlin'), 'W')
Otherwise on some dates with time set to Monday 0:30 It will report as the week before, as it does not take daylight savings into account. I would assume that this new property make this additional SET_TIMEZONE() redundant, right?

Is it also possible to read the timezone that was set via the REST API?