How to filter tiddlers for a certain time period

#1

For example, if I want to filter tiddlers created from 13 January 2025 to 23 January 2025, how do I go about writing a filter?

#2

Hi @dongrentianyu,

I am using this solution Timeline with end-date and not with limit 100 - Discussion - Talk TW:

<<timeline-recent end:"20250011300000000">> <!--YYYYMMDDhhmmss000 Don't forget UTC Time !!! Not local time -->

Stefan

#3

Give this a try:

<$list filter="[all[tiddlers]] :filter[{!!created}compare:date:gteq[20250113]compare:date:lteq[20251123]] +[sort[created]]">
   <<currentTiddler>> created on {{!!created}}<br>
</$list>

-e

1 Like
#4

Thanks, I should be able to get what I want with a little modification. One question for you though, if I have a lot of entries with this filter, will it cause performance lag? Because I want to list ideas for the week.Wouldn’t it be better to wrap it in a macro or some other code?

#5

You should tackle that problem when you have performance problems, otherwise you probably limit your possibilities prematurely.

In the sidebar we do limit long lists by 100. If you filter for 1 week, there should not be too many results.

Once you know, what you want creating a macro will probably make the code easier.

#6

Maybe I don’t express myself particularly well. Since I don’t really speak English, these were translated by the AI. So I apologise if anything has caused any misunderstanding.

My question is, if I have more than fifty tiddlers, all of which are not too different from the above, only the date has changed, will it cause performance lag? If it doesn’t, I’d be inclined to just use the code above, which would make it easier for me to make subsequent adjustments. If it would, I might consider wrapping it in a macro call. But wouldn’t the macro code also affect performance?

#7

Thank you, I will consider this approach as well.

#8

Give this a try at https://tiddlywiki.com:

before <<now "0mm:0ss.0XXX">><br>
found <$count filter="[all[tiddlers]] :filter[{!!created}compare:date:gteq[20120101]compare:date:lteq[20250123]] +[sort[created]]"/> matching tiddlers<br>
after <<now "0mm:0ss.0XXX">><br>

This applies the suggested date filter to find all tiddlers created since Jan 1 2012 (it should report 1600 tiddlers on https://tiddlywiki.com). Note the difference in the value of the time stamps displayed before and after the “found … matching tiddlers” output which shows that it took approximately 30msec to check the created field values of all the tiddlers AND sort the results.

I also ran this same test in another TiddlyWiki that contains over 40,000 tiddlers (!), and it took approximately 500msec.

Thus, it seems like you should NOT have ANY performance concerns for processing “more than fifty tiddlers”.

-e

#9

50 tiddlers should not cause a performance problem. As I wrote, you should tackle the performance problem if you get one.

Yes a macro-call will need some time, but it is in the µs range.

What you try to do here is “premature optimization” at the wrong places.

#10

Thank you for the detailed answer. I do have deep concerns in this area.

#11

Many thanks for the guidance as well, I’m not a programmer and don’t really know much about this. My concern about the performance aspect stems from the fact that when I used to use TiddlyWiki in the past, something very laggy happened, and I don’t know how I solved it later, but I’ve been concerned about performance since then.

#12

The “problem” with performance concerns is, that it heavily depends on the context and it heavily depends on “user perception”.

Eg: If you click a button “Create an overview that lists all tiddlers tagged Z” a delay up to 300-500ms is no problem. Since most users expect a delay after a button click.

On the other hand if you have a text input that dynamically creates a list and you start to type, a delay of 100ms will be a problem, if it blocks the text input. Most users type faster than 100ms per character. So while the delay after a button press is 3-5 times slower the text input “performance” feels worse.

That’s why in the core we use a 3 character limit for some dynamically created lists that depend on text inputs. That’s good for 90% of those interactive of lists, which a “little” change to the wikitext code.

The other 10% need more work, but there still are some new mechanisms in place to tackle those problems. The problem here is, that they need completely new wikitext code. — The good thing is that optimisations are available if needed.

Hope that makes sense.
-m

1 Like