Search/filter a date range until now

I found this post in How can I search for a date range? and I tried the metioned search syntax for date range, but one of them doesn’t seem to work for me:

date:[2021-08-17 to *]

returns all pictures, no only the ones newer than 2021-08-17.

Do I do something wrong? Or is this a bug?

I’m not sure that’s actually a valid date range query. The following should work:

date: >= 2021-08-17

@jimre I tried this but it returns All images.

To be clear: For example

date:2009-04-08

works in the way that it reurns only images taken on 2009-04-08 while

date:>2009-04-08

returns no images (same for date: > 2009-04-08 [with spaces]) and

date:>=2009-04-08

returns all images (same for date: >= 2009-04-08 [with spaces]).

It works fine for me - tried it both on Windows and iPhone. Spaces don’t seem to matter. Using Mylio 3.17 (build 7370) on both devices.

Not sure what’s different in your case?

I suspect these formats work as searches but not as custom filters.

Yes, that’s what explains the difference. I use mainly filters, because they stick around between views.

BTW, @jimre @aearenda, You both are so promptly helpful - amazing! Thanks.

1 Like

So , for filtering the question still stands:

How can I filter a date range until now?

You’re not going to like this, but the old format still works - modified from How can I search for a date range? - #2 by Mylio_Deon - this will filter all images taken on or after 1/1/2018, for example:

media:"datecreated/1000 >= cast(strftime('%s','2018-01-01') as int);"

I’m no SQL expert - there may be a simpler way to do that as a filter.

Yeah this is wrong. I filed a bug.

Try this:

date:[2021-08-17 TO 2099]

and for less than use:

date:[2021-08-17 TO 1600]

(It doesn’t matter which sides of the TO you put the smaller vs. larger date on).

3 Likes

That’s so cool. Thanks.

BTW, when I see the last two replies here, one showing

media:"datecreated/1000 >= cast(strftime('%s','2018-01-01') as int);"

the other showing

date:[2021-01-01 TO 2099]

and both syntaxes (first one SQL, second one Lucene) do the same thing, I ask myself, how is it possible to have two very different search syntaxes in Mylio?

The syntax is set by the media: or date: identifier, I guess!

The complex version is just a pass-thru of raw SQL commands directly to the underlying SQLite database engine. Never really meant for actual humans to use, it was a workaround for Mylio’s (former) shortcomings.

The simple version is a search syntax that Mylio itself interprets; something that non-SQL-expert humans can actually understand. It used to be pretty rudimentary (thus the need for SQL workarounds). But in the last year it was improved tremendously, by incorporating the Lucene search-engine library into Mylio’s code - thanks to the hard work of @Mylio_Deon and others at Mylio.

2 Likes

Ah, yes, now I understand it (Ihope!):of course: Both queries are in Lucene syntax. But the first query is a Lucene query passing the string after media: to the the underlying SQL system which interprets the string as a SQL query, right?

Yes, absolutely correct. Now of course, the SQL version relies on internal implementation details of Mylio that is subject to change release over release. So sometimes we may have to change the way a table or field works, in which case some or all of the media: queries may stop working, and you would have to create a new query. This isn’t frequent but it has happened a handful of times.

However, in the case of our straight Lucene (non-SQL) queries, if we change the SQL, we’ll just update the corresponding query engine to point to the new underlying table or field structures so it will just keep working.

Giving out access to internal structures like this could end up “biting” us if someone gets upset if/when we break it in the future, but so far everybody on this forum have been incredibly supportive and understanding when those things change (like when rootSuffix did in this release). I’d recommend using the officially supported syntax wherever possible, but sometimes you need a bit more power and that’s ok. As long as it’s read/query-only there is really no harm that can happen.

(Please don’t try and write to the underlying SQL though. Because of the way replication works, writing to a database isn’t as simple as just updating fields.)

1 Like

Wow, great explanation.

That’s certainly one reason why I go with Mylio: Your (2nd tier?) support is deep, no-nonsense, knowledgable, honest, and fast!