created field containing repeated NaN's?

[Soren Bjornstad]

While trying to create a button that resets the created date on a tiddler, I absentmindedly tried the following:

\define now-timestamp() <<now [UTC]YYYY0MM0DD0hh0mm0ssXXX>>

<$button set="!!created" setTo=<<now-timestamp>>>

    Created Now

</$button>

Now, I'm aware this snippet doesn't work and can't be expected to because the contents of now-timestamp aren't wikified when the macro call is being used as a transcluded widget-attribute value. I've since produced a correct version. However, I'm still confused about the result of clicking the button: the created field was set to NaNNaNNaNNaNNaNNaNNaN. I'm puzzled by what kind of calculation the setTo attribute of the $button widget is doing that's able to create a bunch of concatenated NaNs. I would have expected to simply get the literal text <<now [UTC]YYYY0MM0DD0hh0mm0ssXXX>> in the field.

Is there something special about the created field in this regard?

[TW Tones]

Try this 

• No need for the separate macro
• Place quotes around the format.

<$button set="!!created" setTo=<<now "[UTC]YYYY0MM0DD0hh0mm0ssXXX">> >

    Created Now

</$button>

Tones

[TW Tones]

Post script,

In this case you will be making the created field lie, it will not be created date but button press date, I suggest using another field to store this date or use modified. It all depends on the logic you have behind it but I recommend using modified and created date as the system uses them because that information will always be true.

Regards

Tones

[Soren Bjornstad]

Tones,

Thanks for your response, and sorry if I wasn't clear in my original post. I have already solved the problem and am not looking for help on that (and I agree that this is probably not a good way to use the created field in most cases). I am instead wondering why I observed the unusual effect I did.

[TW Tones]

Soren,

Implied in my reply (not very well) was the lack of Quotes, I think "[" and "]" would cause the string "format" to be misread. But as you say it is the need to wikify first;

\define now-timestamp() <<now "[UTC]YYYY0MM0DD0hh0mm0ssXXX">>

<$wikify name=input text="<<now-timestamp>>">

<$button set="!!created" setTo=<<input>> >

    Created Now

</$button>

</$wikify>

I have raised the possibility of a simpler way to annotate that a variable be wikified before use.

In your case, without wikify the the created field is being setTo= <<now [UTC]YYYY0MM0DD0hh0mm0ssXXX>>  <!-- the exact string un-wikified -->

In the following case we do not use a macro containing a macro so we need not wikify it first, the now macro is evaluated inline.

<$button set="!!created" setTo=<<now "[UTC]YYYY0MM0DD0hh0mm0ssXXX">> >

    Created Now

</$button>

Display {{!!created}}

Contains {{{ [all[current]get[created]] }}}

Regards

Tones

[Mark S.]

If you clear the created field in a tiddler, save, and then open it again, you'll see the NaNa... displayed. So this seems to be what the field displays when it is empty or contains text it can't interpret. You can change !!created to !!myfield and then indeed see the literal contents of your macro displayed.

[Soren Bjornstad]

Tones, you would think, but adding the quotation marks didn't change the result, and it does appear that (single) square brackets are OK, for instance this is fine:

\define testbrackets(one, two) $one$ | $two$

<<testbrackets [UTC]YYYY0MM0DD0hh0mm0ssXXX another>>

(Double square brackets makes the YYYY part bleed into the two parameter, though, because that's one way of quoting a parameter.)

Mark, this was an intriguing possibility, but I opened the tiddler in a text editor and it actually says:

created: NaNNaNNaNNaNNaNNaNNaN

So it does appear to actually be the text that TiddlyWiki saved in the field.

Maybe the only way to answer this one is by diving into the source code to see what special logic happens when the created field is set. Not that it really matters a whole lot. Just my overactive drive to understand exactly why everything doesn't work speaking here. :-)

[amreus]

I think the "NaN" string comes from this function when the date string is not valid:

$tw.utils.stringifyDate(new Date("20201016232045362"));

NaN is "Not A Number" in Javascript which I assume is where the result comes from.

On Tuesday, February 9, 2021 at 3:28:39 PM UTC-5 amreus wrote:

$tw.utils.stringifyDate(new Date("20201016232045362"));

[Soren Bjornstad]

Aha! That's it for sure. The result of new Date() on the macro string is a Date that prints out as "Invalid Date", and the result of retrieving each of its component parts is NaN. Then:

// Convert a date into UTC YYYYMMDDHHMMSSmmm format
$tw.utils.stringifyDate = function(value) {
    return value.getUTCFullYear() +
        $tw.utils.pad(value.getUTCMonth() + 1) +
        $tw.utils.pad(value.getUTCDate()) +
        $tw.utils.pad(value.getUTCHours()) +
        $tw.utils.pad(value.getUTCMinutes()) +
        $tw.utils.pad(value.getUTCSeconds()) +
        $tw.utils.pad(value.getUTCMilliseconds(),3);
};

As you can see, there are 7 parts retrieved, thus explaining why there are 7 NaNs.

Thanks everyone for helping me satisfy my curiosity :)