Help

Re: Date API confusion

Solved
Jump to Solution
1148 2
cancel
Showing results for 
Search instead for 
Did you mean: 
Steve_Haysom
8 - Airtable Astronomer
8 - Airtable Astronomer

I’m creating a custom app which uses a date input field.

My computer clock is set to GMT+2, ie my time is 2 hours later than GMT.

When I toggle the GMT setting on the date field, the local time appears 2 hours behind the GMT time when using record.getCellValue:

Local date time (GMT setting off): ‘2022-01-01T10:04:00.000Z’
GMT date time (GMT setting on): ‘2022-01-01T12:04:00.000Z’

I can’t understand why the local time is earlier than gmt when it should be later.

Also, I can’t understand why the local datetime string is being formatted as a utc datetime string, as this doesn’t follow ISO8601.

When I use record.getCellValueAsString, it returns the string ‘1/1/2022 12:04pm’, regardless of the gmt setting.

I notice that the datetime string returned by the REST API seems to change in the same way as record.getCellValue, even though the docs say that only a utc datetime string is returned.

Any help/insights appreciated.

1 Solution

Accepted Solutions
kuovonne
18 - Pluto
18 - Pluto

Airtable always stores the date/time as GMT.

Notice that for an editable field, when you toggle between GMT and local time, do the cell values in the user interface change do not appear to change. Instead, under the hood, the cell values that are being stored are changed.

For example, if the field is set to display local time, and you enter 12:04pm, it is actually 10:04am GMT, and Airtable stores the time as 10:04. You then change the field to be GMT. However, notice that the user interface still shows 12:04, except that this is now 12:04 GMT, and Airtable changed the cell value from 10:04 to 12:04 when you changed the field configuration.

When you use getCellValue in your app, you are getting the underlying GMT value that Airtable stores, not the local time, regardless of the display options. However, when you use getCellValueAsString, Airtable applies the field settings (GMT vs local).

When using the REST API, you get the GMT time that is stored, unless you specify a different timezone in your request.

See Solution in Thread

4 Replies 4
kuovonne
18 - Pluto
18 - Pluto

Airtable always stores the date/time as GMT.

Notice that for an editable field, when you toggle between GMT and local time, do the cell values in the user interface change do not appear to change. Instead, under the hood, the cell values that are being stored are changed.

For example, if the field is set to display local time, and you enter 12:04pm, it is actually 10:04am GMT, and Airtable stores the time as 10:04. You then change the field to be GMT. However, notice that the user interface still shows 12:04, except that this is now 12:04 GMT, and Airtable changed the cell value from 10:04 to 12:04 when you changed the field configuration.

When you use getCellValue in your app, you are getting the underlying GMT value that Airtable stores, not the local time, regardless of the display options. However, when you use getCellValueAsString, Airtable applies the field settings (GMT vs local).

When using the REST API, you get the GMT time that is stored, unless you specify a different timezone in your request.

Steve_Haysom
8 - Airtable Astronomer
8 - Airtable Astronomer

Thanks Kuovonne, thats really helpful. I’m assuming that field.options.timeZone is just to inform which timezone the getCellValueAsString value is showing.

I notice that there’s also an option to set the timezone when writing to a cell, but didn’t figure out how to do this, and I’m not sure why you would want to anyway, as the timezone info should be in the datetime string being written.

Note that the timezone property in the field options does not state a specific timezone. Rather, it just says if the client should use UTC/GMT or the local/client time.

Also, you do not specify a timezone when writing to a cell (other than in the date/time string itself). You may be confusing the field value write format with the cell options write format.

Thanks again, yes I was getting confused a bit there.