Advanced dates and API 'Get' Filters

Hi.

I’m trying to perform a JQuery view-based GET on records which are using an ‘advanced’ calendar date (i.e. date range). I want to filter on records that fall within the start and end dates, and possibly the all_day flag. I see that only the field_nnnn_raw contains the relevant data that I want, but I can’t work out the format for the filter string… Can anyone help please?

Hi @Neil1 - might be worth posting what you’ve tried so far.

Another option is to play with filters on a table you’re trying to achieve, grab the url filters and decode them for Javascript. I use meyerwebs decoder/encoder alot for this - URL Decoder/Encoder (meyerweb.com)

Hi there,
First off, there’s limitations in the Date/Time field and how they work with views such as a calendar. If you could, please view this post and upvote it to help shine some light on future improvements: Calendars and Date-Time Fields - All Improvements List

It’s not an exhaustive list, so feel free to add any additional improvements in the comments below. This will hopefully make it easier for the Devs to see it all in one place when they get around to it.

Until then, I made a room booking app a couple years ago. If you need some granularity in your filters, the best thing will be to use text formulas and conditional rules to break-apart your Date/Time field into many fields so that they are individually exposed for your API call and your Views. For example, extract your start date, start time, end date, end time, etc. Don’t forget that after you use a formula to extract these times, you’ll want another field which takes the formula and puts them back into a ‘simple’ date and time field. That way your normal knack comparators will work (ex: start time is today, or this week, etc…these comparators will not work on a formula field or text field for example.)

If you have predetermined views, such as showing all records from Today, you would create a table or another view, and use the built-in filters for the table to filter the records. Then your view-based API call is a simple Get request. If you need more granularity in your API, at least you have the other fields exposed where you can do something with them at that point.

I know this is a long and tedious process to achieve something that I feel should be built-in, which is the reason I created that post above. :slight_smile:

This may not answer all your questions, but hopefully it’s a starting point. Good luck!