Workaround for data validation (date constraints) within Glide? 1 step fwd, 2 back

App scenario:

Purveyors, in different US timezones, sell products during constantly changing sales windows (SW) which they set and update in the app. They enter Start and End datetime values which, if other conditions check out, together populate that SW (e.g., Hours: “Tue Aug 18, 4:00PM - 10:00PM).

The integrity of the majority of calculations in the app is pegged to ease of entering/updating this data and its accuracy.

General conditions:

  • SWs must always start and end on the same calendar day.
  • If setting a new SW, the Start date cannot be in the past.
  • If updating an existing SW (e.g., extending End datetime, Start date can remain in the past.
  • End date cannot be in the past (on or before now)
  • Start date cannot be after End date (/End before Start).

Current Glide limitation:

  • No (date) data validation
  • No way to clear Datetime picker values in GS
  • No date calculations
  • No way to leverage the new default values in a form for a datetime picker component (TMK).
  • No Time picker (only Datetime)
  • Special value Datetime Timestamp is server/device specific (?), not UTC.

1/ My original approach was to enable purveyors to simply edit existing Start and End daytimes (update them) as this allowed for some level of faux date validation through a series of computed columns. With some failsafes in an imperfect formula accounting for the [increment -100000000000000] button workaround for clearing dates in GS.

Until it stopped working (consistently as of 2 days ago) in Glide — components’ visibility is not updating per IF/THEN conditions. An example below is the warning verbiage (“Opening time invalid. please check your dates”) which doesn’t come up when I enter a start date in the past.


2/ Using the form approach, I have zero validation. I am able to extract the most recent record fairly easily but the Data Editor can’t make up its on mind on whether or not to recognize related Start and End dates for that record: lk_newOPEN & lk_newCLOSE. It changes by quite literally the hour.

:point_down:t3: Relevant columns: D, E, H


I’d like to know if someone has managed to bring some type of validation to dates in forms. I try to keep as much out of GS as possible but anything to do with Dates (everything for me) has been challenging.

2 Likes

I am running into the same challenges because app requires that users create a new event no more than 1 week in the future. (The lack of robust data validation across the board is frustrating).

I haven’t given this a lot of thought yet but since the valid days for my use case are limited, I was thinking about creating a custom date picker with a dynamic choice component. However I think that could be overly complex and probably impossible given varying time zones.

I voted for form validation in the feature request app:

1 Like

This piece is perfectly doable in Glide. Other constraints?

I have reworked my approach since this post, moving 20-30% of the validation to Glide. Timezone calculations are still in sheets. Complex, dizzying, but also doable.

Yeah, I found a workaround in this post: Prevent bookings 6 months or more away (in the editor, not the sheet)

Unfortunately there are some UX issues that I am trying to sort through at the moment.

I felt very productive the first 1-2 weeks using glide but for the past 2-3 weeks I feel like I have been arm wrestling with it to polish my app and make it production ready.