Folks, Due to a lack of basic Date calculations in tiddlywiki once again I return to using the days operator which accepts a date field as input, rather than a date or variable, as a result it is unclear in the documentation if the days operator honors the UTC timezone offset.
That is if a date is set using UTC it will be set to universal time and when we make the days comparison with the actual value it will be off, in my +10 time (DST +11) zone it will be out quite a bit.
I can not find utc in $:/core/modules/filters/days.js which defines this operator.
Actions possible once answered;
Update the documentation to describe its use of UTC
Possibly improve allow the days operator to handle UTC or make a UTCDays operator
Document a work around?
[Edited] I also observe the days operator needs a number so to get all in the past you must dive a number eg [days:due[-365]] and unfortunately the value cannot be Infinity or -Infinity
Thanks @Eskha and @EricShulman thanks for sharing your tools but my question is specifically about the days operator, UTC and its documentation.
I will post any more info I gather here but I am hoping for some information to establish the current behaviour so I can use it reliably and contribute to the documentation.
Here’s some information regarding the current behaviour of the days:fieldname[n] operator, based on an examination of the code in $:/core/modules/filters/days.js:
By default, it uses the modified field of each input tiddler. Note that this field (or any other stored date field) is, by convention, always assumed to be stored as a UTC value.
It converts the field value to a date text string using $tw.utils.parseDate
This date text string is subsequently converted to a “timestamp” value with hours set to (0,0,0,0)
To find qualifying titles, it calculates a “targetTimeStamp” Date() object with hours set to (0,0,0,0), using the dayInterval filter operand to calculate days as milliseconds (1000*60*60*24*dayInterval)
It then subtracts the tiddler timestamp with hours=(0,0,0,0) from the targetTimeStamp to determine if the tiddler timestamp isWithinDays by examining the if the sign of the resulting value is positive, 0, or negative.
Note that none of these internally computed values are adjusted for a local timezone offset.
Thus, all comparisons used by the days[] operator are assuming that the tiddler date field values are stored as UTC times.
Since days is a relative day offset, it must also obtain a “now date time” with which to make the comparison. It is this date I assume is UTC so the dates are compared like with like?
The system date fields created and modified are recorded as UTC and converted to your local time zone during display such as with the https://tiddlywiki.com/#ViewWidget
The days operator assumes the data field provided is also set to UTC rather than the local time.
Assuming the “now” is UTC for this comparison, I may add.
To make this comparison internally the days operator uses a UTC time.
Need to test the consequences
Will check that this operates and compares correctly as someone in another time zone would expect.
Once this is all clear
I would be tempted to link to or include advice to use UTC when saving a date/time, and how to.
Agreed regards the doc, I figured out that I needed to stick to UTC because that is what the doc says the tiddler “last modified” and “created” fields use - but it was not crystal clear from the doc.
Personally I would break up the proposed
The system date fields created and modified are recorded as UTC and converted to your local time zone during display such as with the https://tiddlywiki.com/#ViewWidget
I think the second part invites confusion
Suggested…
The system tiddler date fields ‘created’ and ‘modified’ are recorded as UTC
A custom tiddler date field recorded as UTC may be supplied instead of ‘created’ or ‘modified’.
The days operator assumes the date field provided is also set to UTC rather than the local time.
-----------------------------------comment: change of subject --------------------------
UTC recorded dates in tiddler fields are converted to your local time zone for the purpose of display ( such as with the https://tiddlywiki.com/#ViewWidget ) but the stored value in the tiddler field is not altered.
Reason: All doc relating to internal UTC use+representation stay as one text block and then change subject to say how actually displayed adding that internal representation is not altered. I found doc on my travels that did this kind of flipping between internal representation and external display with one sentence and found it less transparent.
Check: Is the last statement true for custom date fields or just modified and recorded?
Footnote: I was confused - thought I was looking at a more current thread on the same subject - however my comments are relevant so I intend to leave here with explanation why I seem to think I am on a live thread