Use SERIAL_NUMBER for Date parsing

[triozer]

Closes https://github.com/framer/company/issues/31732

Description

This pull request use the SERIAL_NUMBER date time render option from Google Sheets to get the correct Date value. Before we were relying on the cell formatted value which could be set to a non-standardized (ISO 8601).

Doing so, we lose the ability to auto-detect dates field (we could add it back by doing another call to the API as we were doing before e.g. using FORMATTED_STRING)

Testing

• It imports date into the CMS
  • Start the OAuth Worker locally
  • Start the Plugin locally
  • Launch the Plugin in Framer
  • Import the With Date sheet from → https://docs.google.com/spreadsheets/d/1o1RaseNzmT1ug5kYQr-LWrHbCWCglOISJpv8jGdxC28/edit?usp=sharing.
  • Set the Published Date column type to Date
  • It imports the correct date (the Published Date should match the expected one)

[tom-james-watson]

Doing so, we lose the ability to auto-detect dates field (we could add it back by doing another call to the API as we were doing before e.g. using FORMATTED_STRING)

What does this mean? What's the implication of this

[triozer]

Before when syncing a spreadsheet, we would automatically detect the date cells as Date. Now they would be detected as Number (being the SERIAL_NUMBER).

Doing two calls to the APIs should be fine, given that until now we only check the row under the header when inferring the type. We could probably reduce the range to only get the second row? Wdyt?

[tom-james-watson]

I followed QA and they were imported like this:

[tom-james-watson]

I'm not sure what you mean by another API call. I've not touched this plugin before so I don't know what past changes have been made, if you're referring to something it previously did. 🙏

[triozer]

@tom-james-watson let me clarify what I meant about the API calls.

Previously, when someone imported a Google Sheet, we would automatically detect which columns were dates by looking at how they appeared in the sheet (using FORMATTED_STRING when calling the Google Sheets API). So if a cell looked like 2024-03-21, we'd try to parse it as a date and say "ah, that's probably a date column!"

In this PR, I switched to using SERIAL_NUMBER to get more reliable date values (since date formatting can be inconsistent). But now we're getting numbers like 45372 instead of formatted dates, which means we have lost that auto-detection ability.

If we want to bring back auto-detection while keeping the reliable date parsing, we could make two API calls:

1. One with SERIAL_NUMBER to get the actual values (what we have now)
2. Another with FORMATTED_STRING just to peek at how the cells are formatted and detect date columns.
   Since we only need to check the first row of data to detect types, we could optimise by limiting the second API call to just that row.

[tom-james-watson]

Nice, I think that would be better yeah, because it's not ideal to have to go and switch all date columns to "Date" type manually. Would that be as part of this PR?

[jonastreub]

Does this work correctly with timezones? We store our dates in Zulu timezone, and we strip off the time, unless the field supports both date + time.

[alecmev]

If we want to bring back auto-detection while keeping the reliable date parsing, we could make two API calls

Didn't we consider using a different API, with richer meta data? I think it was punted on because of being out-of-scope in another PR, but it feels like we keep running into these "loosey goosey schema" issues 😛

[triozer]

… Would that be as part of this PR?

@tom-james-watson yes, I think we should keep the feature!

Didn't we consider using a different API, with richer meta data? I think it was punted on because of being out-of-scope in another PR, but it feels like we keep running into these "loosey goosey schema" issues 😛

Actually yes, we can use the effectiveFormat and try to infer the right type! Will save us another API call!

[alecmev]

try to infer the right type

I don't think it will be "try"! Just effectiveFormat.numberFormat.type === "DATE" (or TIME or DATE_TIME).

[triozer]

Does this work correctly with timezones? We store our dates in Zulu timezone, and we strip off the time, unless the field supports both date + time.

Yes it does! The actual output from Google Sheets is a float, 33.625 is 1900-02-02T15:00:00.000Z.

[triozer]

Let's release this as is to first unblock our users. And add re-add the Date type inferring when handling https://github.com/framer/company/issues/31805.