TWCore format:date filter

#1

As you probably know, I’ve done extensive work with TiddlyWiki time functions (see TiddlyTools/Time/Info).

However, I’ve run into what I suspect is a subtle flaw in the TWCore’s handling for date/time formatting when using the format:date filter operator. Today is the day that the US switches from Daylight Saving Time to Standard Time (changing the time BACK by one hour), and there seems to be an “off by 1 hour” error related to this change in time and the local timezone offset:

Please try the following code at https://TiddlyWiki.com

<$let UTCtime=<<now "[UTC]YYYY0MM0DD0hh0mm0ss0XXX">>>
<$let localtime=<<now "YYYY0MM0DD0hh0mm0ss0XXX">>>
<$let format="[UTC]hh12:0mm:0ssam">
UTCTIME = <<UTCtime>><br>
LOCALTIME = <<localtime>><br>
FORMAT=<<format>><br>
`<<now "hh12:0mm:0ssam">>`  = <<now "hh12:0mm:0ssam">><br>
`{{{ [<localtime>format:date<format>] }}}` = {{{ [<localtime>format:date<format>] }}}

For my timezone (California = Pacific Standard Time = UTC-8), the above code outputs:

UTCTIME = 20251102160729711
LOCALTIME = 20251102080729711
FORMAT=[UTC]hh12:0mm:0ssam
<<now "hh12:0mm:0ssam">> = 8:07:29am
{{{ [<localtime>format:date<format>] }}} = 7:07:29am
  • format:date always expects a UTC timestamp as input, but I am passing it a local timestamp.
  • I am also using the [UTC] prefix on the time formatting string.
  • The expectation is that by using this prefix it will not apply any timezone adjustments to the <time> value input.

As you can see, the UTCTIME and LOCALTIME correctly show a 8 hour difference and the <<now>> macro output also shows the correct local time. However, when using format:date (with the [UTC] prefix), the result is 1 hour behind the actual local time.

This formatting error only appears on the day that the clocks change and I’ve observed this same error in previous years, but have not been able to track down the cause. In addition, this error seems to be somehow related to my timezone offset as it self-corrects after 8 hours (the difference between my timezone and UTC).

To solve this, I need YOUR help. If people in other timezones could try this code and report their results (as well as their current timezone and offset from UTC), I might be able to narrow down the cause (or at least better understand the problem).

Thanks,
-e

#2

An additional catch that might make testing trickier is that in most of Europe we switched from DST two weeks ago (and yes it is infuriating that we don’t all switch at the same time).

Paris, UTC +1

UTCTIME = 20251102163136487
LOCALTIME = 20251102173136487
FORMAT=[UTC]hh12:0mm:0ssam
`<<now "hh12:0mm:0ssam">>` = 5:31:36pm
`{{{ [<localtime>format:date<format>] }}}` = [5:31:36pm](https://tiddlywiki.com/#5%3A31%3A36pm)
#3

India (Kerala)

UTCTIME = 20251102164834401
LOCALTIME = 20251102221834401
FORMAT=[UTC]hh12:0mm:0ssam
<<now "hh12:0mm:0ssam">> = 10:18:34pm
{{{ [<localtime>format:date<format>] }}} = 10:18:34pm
#4

Edinburgh (Scotland) same as UTC

UTCTIME = 20251102172531498
LOCALTIME = 20251102172531499
FORMAT=[UTC]hh12:0mm:0ssam
<<now "hh12:0mm:0ssam">> = 5:25:31pm
{{{ [<localtime>format:date<format>] }}} = 5:25:31pm

#5

Plymouth, UK… same as UTC, I believe:

UTCTIME = 20251102195411175
LOCALTIME = 20251102195411176
FORMAT=[UTC]hh12:0mm:0ssam
<<now "hh12:0mm:0ssam">> = 7:54:11pm
{{{ [<localtime>format:date<format>] }}} = 7:54:11pm

#6

Central/UTC-6

UTCTIME = 20251102224532266
LOCALTIME = 20251102164532267
FORMAT=[UTC]hh12:0mm:0ssam
<<now "hh12:0mm:0ssam">> = 4:45:32pm
{{{ [<localtime>format:date<format>] }}} = 4:45:32pm
#7

Austria UTC+1

UTCTIME = 20251103000731730
LOCALTIME = 20251103010731730
FORMAT=[UTC]hh12:0mm:0ssam
<<now "hh12:0mm:0ssam">> = 1:07:31am
{{{ [<localtime>format:date<format>] }}} = [1:07:31am](https://tiddlywiki.com/#1%3A07%3A31am)

#8

And in Australia, the states that have DST started it another two weeks before that! (first Sunday in Oct - and continues till the first Sunday in April)

However, for completeness of the original request:

I am Australia/Brisbane (+1000) =part of Australia that does NOT have DST, and

UTCTIME = 20251103030316627
LOCALTIME = 20251103130316627
FORMAT=[UTC]hh12:0mm:0ssam
<<now "hh12:0mm:0ssam">> = 1:03:16pm
{{{ [<localtime>format:date<format>] }}} = 1:03:16pm

…none of which is in error.

I suspect with some wrangling of inputs, examples could be found for arbitrary times, rather than testing it on the half dozen times a year (across different places) that have the switch.

(of course, for my taste, the solution is to nuke DST from orbit. It’s the only way to be sure)

#9

Here in Sydney, which does have Daylight savings time, unlike Nemo this is my result and show the current local time with DST; But would it get it wrong unless I set another date before/after DST?

UTCTIME = 20251103035803996
LOCALTIME = 20251103145803996
FORMAT=[UTC]hh12:0mm:0ssam
<<now "hh12:0mm:0ssam">> = 2:58:03pm
{{{ [<localtime>format:date<format>] }}} = [2:58:03pm]

Notes:

  • Does unix time overcome some of these limitations?
  • From memory the format operator accepted other input date formats, I may be wrong.
    I may return with a test
\define date.inputs() 2020-05-05 20200505  2020050513 202005051359 20200505135958 2020050513595857 2020050513595857222
\define output.formats() YYYY0MM0DD YYYY0MM0DD_0hh:0mm [UTC]YYYY/0MM/0DD_0hh:0mm  YYYY/0MM/0DD_0hh:0mm YYYY0MM0DD0hh0mm0ss0XXX [UTC]YYYY0MM0DD0hh0mm0ss0XXX


!!!Now <<now "YYYY-0MM-0DD 0hh:0mm">>, <<now YYYY0MM0DD0hh0mm0ss0XXX>>

;Date formats of now
:Date Format, input date, result | normalised date
<$list filter="[date.inputs[]enlist-input[]]" variable=date>

;input date '<<date>>'
<$list filter="[output.formats[]enlist-input[]]" variable=date.format>


* ''<<date.format>>'' Date-format
* '<$text text={{{ [<date>format:date<date.format>else[nul]]  }}}/>' result
* '<$text text={{{ [<date>format:date<date.format>format:date[YYYY-0MM-0DD 0hh:0MMam]]  }}}/>' renormalised
</$list>
</$list>

;Notes
* renormalised takes the result and formats it with "YYYY-0MM-0DD 0hh:0MMam"
* Partial formats work for days but return different hours
* Using a full tiddlywiki timestamp is returning -1hr pre dst

Place in a tiddler, and review results

  • Only partialy addresses the Topic

My conclusion
At least with partial dates the hours and minutes do not seem deterministic, perhaps the library supporting date handling is a little more robust with dates than when given short dates, times, nuls or zero filled values. Pointing to a problem in the hhmmss part of the timestamp when combined with utc?