Tcl Source Code

The [clock scan] "this" modifier does not work because the lexer strips off the "s" at the end, thinking it's plural.  Writing "thiss" restores its functionality, but the code suggests it behaves identically to "now", so it never needed to exist in the first place.

Therefore, I conclude that no working program has ever used the "this" modifier, and no future program ever will need it, not as currently defined anyway.

Thus, we should be free to remove it from the documentation, even go so far as to remove the implementation too by dropping it from OtherTable.  Either that or explicitly document that "thiss" is the same as "now", but then we'll be well and truly stuck with it.

Background: I decided to investigate while trying to figure out how to get the start of the current day.  "tomorrow" and "yesterday" give the starts of the next and previous days, but "today" gives the current time.  I was hoping "this day" might do the trick, but nope.  "thiss day" works the same as "tomorrow" ("now day" does too).  Looks like I need a different solution.

This has been discussed before ([600832]) and was marked Won't Fix.  Maybe we should revisit this decision.

Trying to fix that I noticed that fixing of plural "bug" does not solve the issue (it'd sometimes act as next sometimes as current unit, related to what it is).

Additionally noticed that several other cases are "wrong", so e. g. "next"/"last" are related to tNEXT(1)/tUNUMBER(-1) yacc tokens, what causes:
<code><pre style="padding-left: 10pt">
% clock format [clock scan "next January" -gmt 1 -base 1554818068] -gmt 1
Thu Jan 09 00:00:00 GMT 2020
% clock format [clock scan "last January" -gmt 1 -base 1554818068] -gmt 1
Sun Dec 30 00:00:00 GMT 2018
</pre></code>
where second result is:
<ul>
<li>invalid</li>
<li>would it be valid (Jan 01), it would in wrong year (2019, try April instead of January)</li>
<li>if it would be correct, there is additional difference between tNEXT and tUNUMBER: in one case day is retained (e. g. remains 09), in other (tUNUMBER) it gets truncated (mean at start of unit).</li>
</ul>

There are much more ambiguities: for example <code>last/next day</code> would truncate time (so again start of the unit), but <code>last/next hour</code> would NOT truncate the minute (just an increment hour related to current base), etc pp.

So the issue grows further. I'll try to provide proper solution for all this (but would fix it only in my new clock-engine or rather in something like clock-speedup-cr3 doe to compat reasons).