My response here is not entirely on point vis-a-vis the thread’s purpose (Sorry @TW_Tones!), but I’ve often wanted to modify the behavior of that “timestamps off” option.
I do often want to manually override a modified date in order to back-date something (so the timeline tracks something meaningful for my readers). But I’ve never wanted new tiddlers to be created without a create date. Unfortunately, “timestamps off” disables automatic creation dates as well as updating of modified dates.
And, as probably everyone who has ever toggled timestamps off can testify, if you FORGET to turn it back on (after doing whatever needing to be tinkered with), it can create a devil of a mess if you then have a slew of tiddlers entirely lacking in timestamps. (Especially if this has happened more than once, so it’s not necessarily simple to cook up a filter to catch just the recent batch.)
How easy would it be to tweak my “timestamps off” toggle so that there’s conditional behavior, so as to prevent free-floating timestamp-less ?
In other words: If a tiddler LACKS a create date when it’s saved (even with “most timestamps paused”), then saving an edit WOULD still give it a created timestamp (on the variation I’d prefer).
(Honestly I don’t care myself whether a newly created tiddler also gets an automatic modified value; I perefer that all tiddlers that I edit should always have some value in the modified field, whether assigned or automatic. For my use-cases, only a plugin shadow tiddler (or possibly tiddlers from some special-purpose reference set) should be present in my wiki without a modified value. But I’m not as worried about this detail. I just want a guardrail against accidentally generating 100%-timestamp-less tiddlers when I’m distractedly working in the shadow of a minor-touches task that required timestamps off.)
Yea, Having no timestamp at all, because you forgot to switch it on - I can feel the pain
As some users wrote in the related thread, they even switch of created, because for a lot of tiddlers it can reduce wiki size.
The usecase you describe is completely different and “domain specific” as so often with TW.
I can see the desire, to date back the modified field to get a tiddler “back into context” in the timeline. For teachers that makes sense, if users remember: “Ahh we did that 2 months ago”, but the tiddler is in the Recent tab 1 week ago, because it needed some typo fixing and Timestamp On was active
I think it would be needed that
If Timestamp is off
The Tool button needs to be forced to be visible
There may be 2 buttons
One for created field update on/off
One for modified field update on/off
Hidden settings:
Do not create created date
Do not create modified date (IMO only for consistency)
I think that would cover all usecases. So IMO it will actually be more work as it first seemed, if it is done consistently. I’m not sure if Jeremy will like that extra complexity. So may be a plugin.
Whether import triggers a change in the modified field is probably also something that should be user-configurable.
I actually cross-transfer a whole bunch of reference and utility tiddlers between my own projects, such as vocabulary definitions, biographical sketches, etc., and I generally appreciate that they by default these retain their existing modification dates. (In other words, especially if I was the one who last modified these resources, it’s especially helpful for me that the modification date stays meaningful as when-this-content-was-actually-last-changed.)
But as you say, workflows and wiki purposes do differ! And in some cases (if I wanted students to see certain new-to-them imported stuff in the timeline, even though most “headline” content is created directly in the wiki for that course, rather than being imported), I occasionally do want the import process to include a “touch” step (token modification to set modified timestamp) for some or all of the tiddlers.
It’s easy enough to add a batch-touch step for an imported group. It would be much harder to reconstruct and restore the incoming modification date, though, if the import were to overwrite that info by default.
I do see the motivation here. Some visual way of flagging “timestamps off” more visibly — maybe even with a RED (or ORANGE) icon, the way the dirty/saved button works! — would be good.
However, I tend to hide the sidebar often. And some people who micro-manage timestamps for readers’ benefit (as with how I care what the Recent tab looks like for my students), the timestamps button may not even be in the page toolbar. (In my case it is, becasue I’ve got lots of author-mode vs reader-mode interface differences. Timestamps icon/button is irrelevant to students, so my readOnly css makes it display:none; only if site is loaded over http without tiddlyhost login — but others who build a page with reader view in mind may just make it invisible…)
I propose that timestamps:off might warrant a visual cue that’s (optionally?) as prominent as the red “draft of…” warning that by default overlays the bottom left. My ideal would be to have something like that, at the top right (near where I look for the dirty/saved icon).
I may even tinker with some workflow that reverts the timestamps-off when the wiki is saved. Whenever I’m doing “clean-up” work, like setting some insignificantly-touched reference tiddlers back to modified:202512312359 (last possible minute of recent year being my go-to “toss it far enough back” convention), I tend not to forget to save that work (even if I forget to turn timestamps back on). And if it saving reverts my setting to timestamps:on before I’m done with the tinkering, I will always notice that fact right away, because the only reason I turn them off is to clean up the recents list, and I will recognize right away if I edit a field directly, or use Commander to back-date a batch, and my change to the modified field doesn’t “take” because timestamps are back on.
I support more fine grained control of timestamps including perhaps an automated reset to on, High visibility when off.
modified time stamps
created time stamps
import timestamps
There may also be a need to allow timestamps to be set in a few more actions but I have not attempted to research this of late.
I would like to see an import timestamp that does not change the modifed date, this would allow us to identify imported tiddlers, their import batch and possibly more.
I will investigate the application of a timestamp on tiddlers installed by bookmarklets when installed without touching created and modified. perhaps also the bookmarklet source name.
for now we need to treat plugins/shadows differently and this may be done with a cumulative log.
On reflection I think we could also investigate the import process for the opportunity to manage tiddlers a little more deterministically. examples may include indicating tiddlers overwritten by imported tiddlers differently to those that do not overwrite tiddlers, perhaps even store tiddlers before import overwrite in a way similar to the trash plugin or import bundles of Mario’s.
Of course if a tiddler has an imported date, we know it came from an import, but did it exist prior to the import?, this is where one could imagine a field containing a list of date stamps when a tiddler was overwritten (except for overwriting this list).
Saving bytes with date time stamps
This makes me return to the earlier thinking that, what would be a good way to encode and decode date/timestamps to save the number of bytes needed to store each timestamp. eg numeric to alphanumeric at least for lists and history etc… the same for other UID as well.
[Edited] Some research suggests an encode/decode that would reduce a TiddlyWiki 17 character date/timestamp to 11 character would be the native javascript base36 with padding retains sort-ability and legal characters.
But perhaps we could could get even more compression?
Perhaps this is a prerequisite to building more date timestamps into tiddlywiki, first coming up with a more compressed date/time stamp ?
