Scripts "timing out"?

[oreocereus]

The relatively recent addition of "default to current date" is really useful on date fields, where 95% of the time the user is going to select "today."

However, it seems that the field doesn't use our local timezone, unless I enable "display time." I don't want to have to enable "display time" as our bases are designed to be used on mobile, so it's always a challenge to keep views succinct. 

Is there a setting I'm missing, or is this a bug in Airtable?

Here's a couple of screenshots:

Showing the variance in the baked in "created date" field and the "date" field, which defaults to current date.

Here is the edit history of the "beetroot" record, showing that the user (me) didn't accidentally select a different date.

[elbabar]

Yep - same problem here using the site from California - any record created past 4pm (ie: midnight GMT) will default to tomorrow's date as opposed to today. You'd think Airtable being based in SF they would handle such "edge cases" for the 95%+ of users who don't live on GMT, especially for such a basic functionality. Just bad product management. You can get around it by programming your own automation to create the default.

[oreocereus]

Yes its very frustrating. Airtable support said they know of the issue and have no timeline for resolving it 🙄

And yes, can get around with it via automations and formulas, but I'm already at max automations for our plan - a number of automations are there to account for these sorts of bizarre issues already. To be honesty, a bit disappointed we've invested ourselves so deeply into airtable when these sorts of issues seem to persist for years.

[elbabar]

Knowing how startups work, and that their last round of funding in 2021 was at an insane $10B+ valuation, they may be investing all their time and effort on "groundbreaking" AI features to justify their valuation ahead of an IPO. Their annual revenue is $150M so we (paying users) don't matter nearly as much in this picture I'm afraid.