It would help if you could post your test tiddlers, or even your entire TW file (like at tiddlyhost.com) Otherwise we each have to hand-create the data, leading to more errors.
Good luck!
Filter.json (527 Bytes)
1 day ago.json (130 Bytes)
2 days ago.json (131 Bytes)
3 days ago.json (131 Bytes)
4 days ago.json (131 Bytes)
5 days ago.json (131 Bytes)
Notice how the number of listed items does not decrease by one when parameter goes from -3 to -4.
Note:The titles will be “outdated” soon since we are close to UTC date changing.
Here’s my version to display the dates.
\procedure dueit(offset)
filter=[!days:due[<<offset>>]]<br>
<$list filter="[!days:due<offset>]">
<$link/> | {{{[<currentTiddler>get[due]format:date[]] }}}<br>
</$list>
<p/>
\end
<$list filter="[range[-1,-5,-1]]" variable="offset">
<$macrocall $name=dueit offset=<<offset>> />
</$list>
What we need is a screenshot of what you see, plus the local time when you see it. And I know you may have to tweak your data now because time marches on. I had to reset all the data, picking a noon time just to make the math easier. Once I did that, everyone looked as expected.
Ha! This might be the most confusing week of the year to be comparing timestamps!
Interestingly, on the same machine, I get 2 different results on 2 different browsers:
-
Firefox:
-
Vivaldi:
Both run on linux, but I use Enhanced Privacy Settings on Firefox which set apparent time to UTC.
So I guess the problem is somewhat linked to local time conversion…
Fred
This! 
You made my day with this one!
“Ha! This might be the most confusing week of the year to be comparing timestamps!”
Wait. It is starting to make sense now.
26th october our local time moved 1 hour back when daylight saving time ended. That is the date where the one day offset happens.
Since the days filter does not seem to care about the time, only the date (making it effectively 00:00), I believe at some moment in the comparison the changing daylight saving time gives -1 hour, moving the date to previous one (before midnight).
Can’t quite wrap my head around how to fix it.
You can try 2 options:
- Use and store only UTC dates
- Store local dates with a timestamp of 120000000. This reduces the risk that a timezone offset will make a date cross the “day changing line”.
Fred
tiddlers.json (2.4 KB)
Here is a screenshot and relevant data tiddlers with the help of your code. The one hour change in local time when daylight saving time ends (26.10.2025 03:00 happens twice: UTC 00:00 and 01:00) causes the whole 26.10.2025 date and all the earlier dates appear “due” one day too early.
Hopefully someone like @pmario can tell us if this is a bug. It looks like the -6 day is also wrong.
Observations;
If you want to set dates at no particular time, with a timestamp value, rather than use midnight, its often a good idea to use 12 noon, as this is in the middle of the day and less likely to flip the days count, it is actualy more relavant on many occasions. However by only using the first 8 digits of a time stamp and taking carful account of UTC and when and how you set it, this can be simplified. Of course created and modified dates are full tiddlywiki time stamps and I recomend you dont touch them so they are reliably represent what they are (in UTC).
Days operator, I went deep in my research of the days operator in the past, and to be honest I dont use them much because they are prone to introducing problems with the way they operate, used incorrectly they quickly switch direction when you use negative days and the negation ! The best way to use them is often a combination of two “days” operators to restrict the results to a range that does not run to infinity forwards or backwards.
- There may be value a in developing a new simpler to use operator, starting with some support for date ranges with custom “functions” to hide some of the complexity.
I do not really know, where the problem comes from. More experiments needed.
The code for the days filter is at: TiddlyWiki5/core/modules/filters/days.js at master · TiddlyWiki/TiddlyWiki5 · GitHub where you can see, how it is calculated.
IMO the problem here is that the targetTimeStamp = (new Date()).setHours(0,0,0,0) hours value is set to midnight UTC, which may cause problems if the DST changes.
I do not know if it would be better to set the “days detection” to 12:00 noon. (I did some experiments. No change in behaviour.)
There has been an old discussion about the days operator from the programmer who implemented it:
Filter tiddlers by date: today and in the past – That’s probably not helpful with the problem, but may be some content to improve the documentation.
There is something strange going on with the test-data provided. (I am testing at Oct. 31) hence my different ranges.
I think there is a bug. But it’s too late to test in detail. I’ll create a GH issue.
I did do a little refresh/research just now, and as I recall the following are highlighted issues;
- The issue is comparing local time vs UTC because they can be in different days, this get worse the further you are for UTC as I am at +11.00 in DST here in Sydney.
- Exacerbating the above the days operator code pins everything to midnight, it does not take note of time of day. its not so much about 24 hour periods, sometimes using a 24hours period may have more suitable results
- For thus Unix time can be used and there is a number for -24 hours.
- An empty date field will be zero and treaded as today.
- To get a closed range you will often need to combine two days operators, because most uses (except for today) return a range of dates (that is why we use it)
- Where in the JS or in wikitext/tiddlywiki script or tiddler fields? I believe the JS forces midnight before comparing.
We kind of need a test-data generator, since every day the target day (now!) changes.
But in this case @uusminuus is at UTC+2, so that shouldn’t be a problem.
Mohamad had a tool for that that could create sets of tiddlers on demand, however its arguably trivial to make a test generator for a specific need.
- A list widget containing create tiddler and field mods inside a it, wrapped in a button (tag=div)
I will pop over to the meta Topics as I just got a message
Site is under extreme load, search is disabled, try again later
Yes, I did this batch change generation through this approach How to have your code and action it too - batch operations on multiple tiddlers, refactoring your wiki
Sorry bad wording. I meant there is something going on with the code as can be seen with the test data provided and my screenshot. The test-data itself is OK.
It’s not as trivial in this case because you need to provide a series of UTC timestamps, custom made for whatever timezone the user happens to be in. And we have almost no tools for manipulating dates.
Mark, I would be surprised, I will make something specific to this test data if you wish?
Thanks, but that’s all right. If pMario says there’s something wrong with the results, then that’s as far as I would care to go. Perhaps someone else would want to take if further.
1 Like
I think to address my own questions I may explore this and related questions today including;
- refresh the test tiddlers in @Mohammad example to around now.
- provide to the user/ designer
- local timezone name
- daylight savings indicator
- current offset from utc
- other useful information as it arrives
Feel free to ask if you can imagin something that may have assisted you, or could in the future.