Skip to main content

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. iupdate 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.

Timezones are ultra annoying to manage with cross-state teams. This could be super useful!


Excellent ⏰ Can’t wait to try this out.


Amazing!! A much appreciated update that’ll work wonders in keeping the whole team on the same page.


This is a great new feature!



Can you please clarify if this affects the REST API or scripting? When retrieving or setting date/time values with a custom timezone, will the underlying value still be GMT or will they be in the custom timezone?


This is a great feature - thank you and the Airtable team!



Why can’t we set the timezone for date fields without times. I know that sounds weird, but we use date (only) fields for task due dates, and then adjust those dates in other fields with formulas. The fact that date (only) fields must be in GMT then messes up offsets due to timezone differences.


This is a great feature - thank you and the Airtable team!



Why can’t we set the timezone for date fields without times. I know that sounds weird, but we use date (only) fields for task due dates, and then adjust those dates in other fields with formulas. The fact that date (only) fields must be in GMT then messes up offsets due to timezone differences.


This has been one of my biggest source of data bugs I’ve encountered through my entire use of Airtable over the years - in that, to have a Date Only column, it’s locked to GMT as the timezone until you display the time… but this isn’t desired for what’s meant to be a date only column… so then a workaround formula column is needed to address this problem of showing a date only from a Date Time column.



It would be good to see the end of this confusion of Date only columns knowing what timezone that they persist in.


Thanks so much for this, @Elena_Jia! This is a very powerful & exciting new addition that will hopefully solve at least half of the time zone problems that people have with Airtable! :grinning_face_with_big_eyes:







  1. However, one big missing piece of functionality here is that normal Date fields (without the time displayed) need to gain this same functionality as well. As it stands now, Date fields (without the time displayed) create the same headaches for people as Time fields do, because people can’t control how the actual date is seen under-the-hood. Ironically enough, somebody just posted about this very problem a few hours ago in this thread.







  2. It seems like you made a grammatical error in this sentence — could you please clarify what this means? "Syncs involving new time zones are currently based on the displayed time. They will be based on the underlying timestamp instead."







Thanks again for adding this into the product! :grinning_face_with_big_eyes:


I am pleased to see that the custom time zone also is listed when creating filters for views and conditions for automations.



I also really like how the time zone picker shows the UTC offset.



I like how the time zone is stored in the field options, as revealed by scripting.



It looks like the underlying format for storing the datetime value is still GMT/UTC, as displayed by a formula field and scripting. So, I’m guessing this has no impact on using the REST API or Scripting.



I would also like to have custom time zones apply to date only fields.


This is a great new feature!



Can you please clarify if this affects the REST API or scripting? When retrieving or setting date/time values with a custom timezone, will the underlying value still be GMT or will they be in the custom timezone?


Thank you, Kuovonne!



In public APIs, when writing a date string to a column with custom time zone, ambiguous inputs like “2020-09-05T07:00:00” and “2020-09-08” will be interpreted to be in the field time zone, and nonambiguous inputs like “2020-09-05T07:00:00.000Z” (GMT) and “2020-09-08T00:00:00-07:00” will be interpreted correctly as is.



Reading a date time cell value will still return an ISO 8601 formatted date in UTC like “2014-09-05T07:00:00.000Z”.



And yes, the underlying format for storing the datetime value is still GMT/UTC. 😀 For REST API, we can potentially set cellFormat as string to obtain date time corresponding to the custom time zone; and in Scripting, getCellValueAsString will achieve this as well.


Thank you, Kuovonne!



In public APIs, when writing a date string to a column with custom time zone, ambiguous inputs like “2020-09-05T07:00:00” and “2020-09-08” will be interpreted to be in the field time zone, and nonambiguous inputs like “2020-09-05T07:00:00.000Z” (GMT) and “2020-09-08T00:00:00-07:00” will be interpreted correctly as is.



Reading a date time cell value will still return an ISO 8601 formatted date in UTC like “2014-09-05T07:00:00.000Z”.



And yes, the underlying format for storing the datetime value is still GMT/UTC. 😀 For REST API, we can potentially set cellFormat as string to obtain date time corresponding to the custom time zone; and in Scripting, getCellValueAsString will achieve this as well.




This sounds perfect! Thank you for digging into this and sharing the results.



Another question – how does this interact with forms?



I created a form with a custom timezone that is not my local timezone and went to fill it out. I clicked the “Today” button in the picker, which normally gives me the current date and time. Clicking that button still looks like it gives me the “current” date and time, but it is the current date and time for my local timezone, not for the timezone set for the field.



I’m not sure what the expected behavior should be. It would be a bit weird for me to click “today” expecting the current date/time and see a different date/time. However, in order to actually store the current date/time, it would need to be a different time.


This is a great feature - thank you and the Airtable team!



Why can’t we set the timezone for date fields without times. I know that sounds weird, but we use date (only) fields for task due dates, and then adjust those dates in other fields with formulas. The fact that date (only) fields must be in GMT then messes up offsets due to timezone differences.


Thank you for the feedback! @egordin @Karlstens @ScottWorld @kuovonne



We scoped adding time zones for date only fields out of this launch, but we will keep an eye out for feedback on this and investigate the behaviors to potentially address it in the future.




This sounds perfect! Thank you for digging into this and sharing the results.



Another question – how does this interact with forms?



I created a form with a custom timezone that is not my local timezone and went to fill it out. I clicked the “Today” button in the picker, which normally gives me the current date and time. Clicking that button still looks like it gives me the “current” date and time, but it is the current date and time for my local timezone, not for the timezone set for the field.



I’m not sure what the expected behavior should be. It would be a bit weird for me to click “today” expecting the current date/time and see a different date/time. However, in order to actually store the current date/time, it would need to be a different time.


Thanks for testing the feature and pointing out the issue! The current behavior of clicking “Today” in the date picker will enter the local date and time values. We will take note of feedback on this as well.


Thank you for the feedback! @egordin @Karlstens @ScottWorld @kuovonne



We scoped adding time zones for date only fields out of this launch, but we will keep an eye out for feedback on this and investigate the behaviors to potentially address it in the future.




Thanks, @Elena_Jia! :smiling_face:


This is a nice development: It’s nice to see the timezone. But I don’t see the timezone list, as you show it in your post. What am I missing?


This is a nice development: It’s nice to see the timezone. But I don’t see the timezone list, as you show it in your post. What am I missing?




After you sign up for the beta, you may need to clear cache before the new features show up. At least that’s what I had to do.




After you sign up for the beta, you may need to clear cache before the new features show up. At least that’s what I had to do.


Thanks, Kuovonne. That did the trick. 🙂


Question about daylight savings - @Elena_Jia



Right now, the date and time are displayed in America/Los_Angelas timezone, which is PDT (UTC−07:00). After the daylight savings on 11/6, it will change PDT to PST (UTC−08:00).



For the meeting that has already been scheduled, after the daylight savings change, it will stay at the same time correct? Meaning, 9 am PDT before 11/6 and it will still be 9 am PST after 11/6.



Thanks!


Question about daylight savings - @Elena_Jia



Right now, the date and time are displayed in America/Los_Angelas timezone, which is PDT (UTC−07:00). After the daylight savings on 11/6, it will change PDT to PST (UTC−08:00).



For the meeting that has already been scheduled, after the daylight savings change, it will stay at the same time correct? Meaning, 9 am PDT before 11/6 and it will still be 9 am PST after 11/6.



Thanks!


Great question! Keen to hear on the handling of this Daylight Savings scenario.


Question about daylight savings - @Elena_Jia



Right now, the date and time are displayed in America/Los_Angelas timezone, which is PDT (UTC−07:00). After the daylight savings on 11/6, it will change PDT to PST (UTC−08:00).



For the meeting that has already been scheduled, after the daylight savings change, it will stay at the same time correct? Meaning, 9 am PDT before 11/6 and it will still be 9 am PST after 11/6.



Thanks!


I would assume ALL time is stored in UTC where there is no DST. The time is not relative to 9am PDT before 11/6, it is relative to UTC before 11/6. 9am is 9am, only its relation to UTC changes on a given date.



My guess answer is, yes 9am PDT will remain 9am PST only the UTC offset will change.


Question about daylight savings - @Elena_Jia



Right now, the date and time are displayed in America/Los_Angelas timezone, which is PDT (UTC−07:00). After the daylight savings on 11/6, it will change PDT to PST (UTC−08:00).



For the meeting that has already been scheduled, after the daylight savings change, it will stay at the same time correct? Meaning, 9 am PDT before 11/6 and it will still be 9 am PST after 11/6.



Thanks!




Yes, all date/time fields are stored in UTC. You can see this by looking at the value through scripting, the REST API, or even a formula field that converts the raw date/time to a string without formatting.





I think you mean that 9am PT on a particular date will remain 9am on that date regardless of whether the the current date is in PDT or PST.




Yes, all date/time fields are stored in UTC. You can see this by looking at the value through scripting, the REST API, or even a formula field that converts the raw date/time to a string without formatting.





I think you mean that 9am PT on a particular date will remain 9am on that date regardless of whether the the current date is in PDT or PST.




Yes, that is what I mean, a set date field will not change when your local time changes in and out of DST.



@kuovonne Do you know if the a date field is a seconds count from epoch? 00:00:00 1/1/1970?




Yes, that is what I mean, a set date field will not change when your local time changes in and out of DST.



@kuovonne Do you know if the a date field is a seconds count from epoch? 00:00:00 1/1/1970?




Dates are stored internally in ISO 8601 format. If you need to know the seconds count from epoch, you can use



VALUE(DATETIME_FORMAT({date}, 'X'))


Thank you for the feedback! @egordin @Karlstens @ScottWorld @kuovonne



We scoped adding time zones for date only fields out of this launch, but we will keep an eye out for feedback on this and investigate the behaviors to potentially address it in the future.




I happened to be thinking about this when I was filling out the beta feedback form. I realized that adding timezones to date only fields is actually far more complex than it appears on the surface.



I decided to mention this here on this thread as well as in the beta feedback form for other people who may wonder why adding timezones to dates was not yet included.



I’m also just guessing here about the complexity, so feel free to correct any of misunderstandings.







  • Date only fields currently do not store a timezone in the field options. Date time fields already had a timezone section in the field options that previously included only “utc” and “client”. It is much easier to add a new timezone to that existing list, versus adding timezone information where it doesn’t exist at all. Adding a timezone field option that didn’t exist at all before would have a greater impact on scripting, custom extensions, the meta api, etc. in addition to internal code.







  • Displaying a dateTime field with a fixed timezone is only a display issue. It is still stored as a ISO 8601 date time string under the hood. This means that there are no underlying data conversion issues.







  • Date only fields do not display a time but are actually stored as UTC midnight. Adding a timezone to these date only fields might require that the date be something other than UTC midnight. The actually timezone offset would also need to be based on whether or not the timezone observes daylight savings time and whether or not the date was in daylight savings time. This also requires special care for dates before and after the transition between daylight savings time and standard time.







  • There might also be implications for date base filters, especially the “is today” filter. These filters are spread across views, automations, and interfaces.







So, thank you for making timezone formatting options available for dateTime fields, even though there are still issues to work out for dateOnly fields. I have confidence that Airtable will work through these issues and come up with an implementation in time.




I happened to be thinking about this when I was filling out the beta feedback form. I realized that adding timezones to date only fields is actually far more complex than it appears on the surface.



I decided to mention this here on this thread as well as in the beta feedback form for other people who may wonder why adding timezones to dates was not yet included.



I’m also just guessing here about the complexity, so feel free to correct any of misunderstandings.







  • Date only fields currently do not store a timezone in the field options. Date time fields already had a timezone section in the field options that previously included only “utc” and “client”. It is much easier to add a new timezone to that existing list, versus adding timezone information where it doesn’t exist at all. Adding a timezone field option that didn’t exist at all before would have a greater impact on scripting, custom extensions, the meta api, etc. in addition to internal code.







  • Displaying a dateTime field with a fixed timezone is only a display issue. It is still stored as a ISO 8601 date time string under the hood. This means that there are no underlying data conversion issues.







  • Date only fields do not display a time but are actually stored as UTC midnight. Adding a timezone to these date only fields might require that the date be something other than UTC midnight. The actually timezone offset would also need to be based on whether or not the timezone observes daylight savings time and whether or not the date was in daylight savings time. This also requires special care for dates before and after the transition between daylight savings time and standard time.







  • There might also be implications for date base filters, especially the “is today” filter. These filters are spread across views, automations, and interfaces.







So, thank you for making timezone formatting options available for dateTime fields, even though there are still issues to work out for dateOnly fields. I have confidence that Airtable will work through these issues and come up with an implementation in time.


Daylight Savings Time is very tricky. Do we know where Airtable is getting the DST details? Around the word the rules change all the time, territories join other territories and adopt a new rule set. While other territories do not recognize DST at all. A place’s time zone UTC offset changes or does not change in accordance with other territories.



Not even the US is immune for example: Arizona does not observe DST, yet the Navajo territories within Arizona do observe DST, and there are territories within the Navajo territories that do not.



Not to mention, some places change in :30 min increments to DST.



The deeper Airtable dives into Time Zones will be interesting to watch for a global solution.


Daylight Savings Time is very tricky. Do we know where Airtable is getting the DST details? Around the word the rules change all the time, territories join other territories and adopt a new rule set. While other territories do not recognize DST at all. A place’s time zone UTC offset changes or does not change in accordance with other territories.



Not even the US is immune for example: Arizona does not observe DST, yet the Navajo territories within Arizona do observe DST, and there are territories within the Navajo territories that do not.



Not to mention, some places change in :30 min increments to DST.



The deeper Airtable dives into Time Zones will be interesting to watch for a global solution.




Daylight Savings Time is very tricky. Do we know where Airtable is getting the DST details? Around the word the rules change all the time, territories join other territories and adopt a new rule set.





Thanks for bringing this up. This is a good point! @Vivid-Squid


Currently we use the IANA timezone data to obtain zone offsets and handle date time conversions between time zones. We will need to keep our data updated in case of changes like the ones mentioned.


Reply