The example tiddlers only have 7 zeros after date
Eg
Five days before due: 202510240000000
The dates you are showing are UTC, not local. So to understand better what is going on, you would need to convert those dates to your local time.
Hi @uusminuus
I think the problem is the date format.
Your format is [UTC]
the format in the example was
<td><$view field=due format=date template="0DDth, MMM, YYYY"/></td>
Your format should be something like
<td><$view field=due format=date template="[UTC]DDth MMM YYYY" /></td>
Sorry @Mark_S
it took me so long to answer I hadn’t realised that you had already replied.
I’m unsure about the date field can you call it date or is this reserved in some way?
Hello, thank you for joining in helping.
My local time is UTC+2. I was not within 2 hours of midnight when noticing this problem. The problem happened when I used automatically saved timestamp in a field in UTC format. But I can’t resolve this by just changing the time part of the timestamp.
The problematic change in behaviour in my example screenshots happens when I change the timestamp by exactly one day and the parameter by exactly 1. The change in behavior happens when parameter goes from -3 to -4.
When parameter is -3, it does filter out a tiddler with timestamp that is 2 days ago (as I’d expect).
When parameter is -4, it does not filter out a tiddler with timestamp that is 3 days ago (why?)
I am so confused how does this arise.
Hello @uusminuus
I am afraid that you are not alone in finding this date formatting stuff confusing.
A general search on [UTC] shows this.
@EricShulman and @TW_Tones Converting a date from local time to UTC is the first of many.
They are more experienced in using TW than I and I am sure they will participate in this discussion before long.
1 Like
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.