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 :)
On Tuesday, February 9, 2021 at 2:31:55 PM UTC-6 amreus wrote:
> 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"));
>>
>
>>
>>
>> On Monday, February 8, 2021 at 10:04:03 PM UTC-5 Soren Bjornstad wrote:
>>
>>> 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. :-)
>>>
>>> On Sunday, February 7, 2021 at 11:00:38 PM UTC-6 Mark S. wrote:
>>>
>>>> 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.
>>>>
>>>> On Sunday, February 7, 2021 at 9:29:43 AM UTC-8 Soren Bjornstad wrote:
>>>>
>>>>> 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?
>>>>>
>>>>
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/1d05c53e-69bb-4dad-89df-3621886dedden%40googlegroups.com.
