Convert created/modified field value to UTC and use it as value for HTML datatime attribute

#1

I’m trying to use the value of created and modified field in the datetime HTML attribute, like so:

<time datetime="YYYY-MM-DDTHH:MMZ">local time format her</time>

The W3C states that the value of the datetime attribute should always be in UTC (Zulu) as it is read by machines and they do the conversion. While the human-facing time is the one between <time></time>.

The code I came up with is:

<time datetime={{{ [{!!modified}format:date[YYYY-0MM-0DDT0hh:0mm:0ss]] }}}>{{!!modified}}</time>

And the result is:

<time datetime="2024-10-07T01:34:23">Mon Oct 07 2024 01:34:23 GMT+0800 (Philippine Standard Time)</time>

Two issues I’m stuck:

  1. I can’t figure out how to change the dateformat in {{!!modified}} so it will display in the ISO format.

    If I use this raw:

    {{{ [{!!modified}format:date[YYYY-0MM-0DDT0hh:0mm:0ss]] }}}

    It outputs an anchor link. (Other than I can’t make it to convert to UTC.)

  2. The value in datetime is local time (see attached screenshot). Inserting [UTC] is not working.

    {{{ [{!!modified}format:date[[UTC]YYYY-0MM-0DDT0hh:0mm:0ss]] }}}

    Continuing the discussion from Converting a date from local time to UTC:

    tiddlywiki-convert-to-utc
    tiddlywiki-convert-to-utc1279×590 66.3 KB

    As shown in the screenshot, the format:date is giving the local time. It matches my desktop clock as well as the other ways to output the time via TiddlyWiki. While the one with a [UTC] prefix outputs the correct UTC time.

    Is it a bug since it’s no longer giving a UTC value? Or, was it changed? In any case, is there a way to set [UTC]?

Thank you again for the assistance and insights!

#2

You can’t use square brackets inside a constant value in a filter.
You must use a variable to store the format string like this:

<$let myformat="[UTC]YYYY-0MM-0DDT0hh:0mm:0ss">
{{{ [{!!modified}format:date<myformat>] }}}
</$let>

Fred

2 Likes
#3

You can use the view widget like this:

<$view field="modified" format="date" template="YYYY-0MM-0DDT0hh:0mm:0ss"/>

Fred

1 Like
#4

Based on my previous answers, your global code could be:

<$let myformat="[UTC]YYYY-0MM-0DDT0hh:0mm:0ss">
<time datetime={{{ [{!!modified}format:date<myformat>] }}}><$view field="modified" format="date" template="YYYY-0MM-0DDT0hh:0mm:0ss"/></time>
</$let>

Fred

1 Like
#5 
<$view field="modified" format="date" template="YYYY-0MM-0DDT0hh:0mm:0ss"/>

While testing this code, I found that Firefox on linux doesn’t give the expected result for the ViewWidget, but instead displays modified field as UTC.
It might be related to my configuration where my hardware clock is set as UTC and system time is set as local time.
Anyway, the same code works normally on the same machine with Vivaldi browser.

This code based on a text widget behaves the same as the view widget on my machine (UTC on Firefox, Ok on Vivaldi):

<$text text={{{ [{!!modified}format:date[YYYY-0MM-0DDT0hh:0mm:0ss]] }}}/>

Weird!

Fred

1 Like
#6

As my quoted comment says:

the INPUT for the format:date[...] filter is always assumed to be UTC

But your observation (“it’s no longer giving a UTC value”) is about the OUTPUT of the format:date[...] filter, which automatically converts the output to your local time zone, unless the format has a [UTC] prefix. Thus, it is NOT a bug, and hasn’t changed.

-e

1 Like
#7

Ahh! I was starting to consider a variable but I haven’t reached that level yet in learning TW, I didn’t realize it’s the correct way! Thank you!

Ah! I misunderstood, apologies and thank you for pointing that out. :slight_smile:

Thank you again, everyone’s helpful in TW community. And apologies for the delay in replies.

1 Like
#8

So to be clear modified and created dates are already in UTC so if you want to see them as UTC you need to make sure they are not converted to local time as they are by default.

#9

I eventually found the cause of this weird behavior: it’s a consequence of Firefox’s “Resist Fingerprinting” setting, which makes times appear in the wrong timezones.
Source: https://support.mozilla.org/en-US/kb/resist-fingerprinting

Fred