UTC and Days operator question

#1

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

#2

Hello TW_Tones,

To adress basic date calculation in some use cases:

  • I convert the date to a timestamp (elapsed time in milliseconds since 1 January 1970 UTC)
  • I do the calculation on time
  • Then I convert back to date

I have written some helpers macros for this on:
Dates macro — Demonstration page (tiddlyhost.com)

Maybe this can help.

BR

Eskha

#3

See also:
https://tiddlytools.com/timer.html#TiddlyTools%2FTime%2FConvertDate%2FFilter
and
https://tiddlytools.com/timer.html#TiddlyTools%2FTime%2FConvertDate%2FMacro

-e

#4

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.

#5

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.

-e

1 Like
Today, Yesterday and Tomorrow with Days Filter Operator
#6

@EricShulman thanks for your research.

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?

Given your research I am tempted to add to the documentation in https://tiddlywiki.com/#days%20Operator something 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.

A Test date tiddler for testing. Date test tiddler.json (2.5 KB) v0.0.1

#7

Thanks Eric, :+1: I believe I am supplying the correct UTC formatted times but I am not making any assumptions - “debug mode” - trust nothing!

#8

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 :grinning: