This would be useful for setting the right time block to sync to Google Calendar.
On the other hand, it would make search a bit more tricky. For example, if an event runs from 22 hours from now to 28 hours from now, should it be included when you search for within:24h?
I think so. I canât think of a situation where I would want to search for items based on their ending time. Starting time is usually much more important.
I guess the question can to reversed⌠imagine itâs in the past rather than in the future. If the end time falls in the search query but not the start time, should it count?
I think so again. If an item has a time range, it exists at every point within its range.
The within search only concerns starting times, whereas the search for the past only needs to concern end times. I think each search still only needs to be concerned with one time.
Once this is a feature, Iâll probably request a search based on durations feature!
How about instead of being concerned about end times, you just add a 2nd parameter for âdurationâ and leave the rest of search alone?
If I search for within:3d or -within:1m, leave the search results exactly as they would happen now.
If I want an all day event, something like !(2017-02-10 00:00+24) or +4 for a 4hr event. As an added bonus, make the duration another search parameter.
Duration:24h would result in all day events or duration:7d would throw up the week in Disney you have planned.
That sounds like a good idea overall, but +4 is very easily confused with timezone indicator. If you turn on âShow timezoneâ in Date settings and insert a date, youâll understand what I mean.
Just wanted to chime in that I would find this extremely useful for calendar sync. Currently itâs hard to integrate the syncâd events with other things placed on the calendar, since the dynalist events are âone dimensionalâ and the others are âtwo dimensionalâ.
Thanks for the input! Yes, we do imagine date range and recurring dates to work well with the Google Calendar integration 
Just wanted to expand a little about ranges. I believe that it would be great if we can look beyond dates only. Often, when you need to represent progress, you donât need dates, but instead plain numbers (number of times you need to do some task per each week f.e.), percents or even colors. In all these cases just dates ranges is simply not enough.
So I suggest to have a syntax that can have not only dates, but also other types of input variables.
Following @Erica suggestion Iâm linking topic with such suggestion and examples of such uniform syntax.
So I suggest to have a syntax that can have not only dates, but also other types of input variables
The TaskPaper format allows tags to have a value, so it could handle all of these use cases.
For example:
- task with a date range @start(2018-11-11) @due(2018-11-13)
- task with a duration @start(2018-11-11) @duration(90)
- repeating task with a due date @due(2018-11-10) @repeat(+1 month)
Then the user can build a custom search using these values. For instance, to find all tasks that are started and due:
@start > [d] now and @due < [d] tomorrow
https://guide.taskpaper.com/reference/dates/
https://guide.taskpaper.com/reference/searches/
Hi everyone, could I check on the state for this feature request? Would love to subscribe to Dynalist Pro just out of this feature!
Hi Huan,
Because weâre only a 2-person team with many priorities, we never set release dates for any features as lots of unforeseeable problems can arise and we donât want to disappoint people who wait for it. Thanks for understanding!
The good news is that it will most likely be a free feature, not Pro feature 
Haha got it! Would love to help more materially if thereâs such a possibility. Iâm a strong believer of making what you use. Thanks for response!