custom timestamp fields?

[grundyunderhill]

Hi all,

Is there any way to make TW treat a user-defined field as a timestamp, like it does for the built-in "created" and "modified" fields?

My use case is that I want to capture timestamps of other events (besides creation and modification), and be able to perform Date-related calculations against them.  Closest I've come so far is saving a string in same format as it uses for "modified", and writing a custom filter operator which calls $tw.Tiddler.fieldModules.modified.parse() to convert string to Date object.  It works, but I feel like it would be cleaner if I could just check whether it's a Date already, and ignore everything else...

Thanks,

Nutt

[TonyM]

Nutt,

I use date stamps a lot, especially to drive periodical items, for example a weekly-review field with a date stamp becomes due again once the date stamp is older than 7 days. I do not touch javascript.

Here are some quick leads.

• Set a field to the result of <<now "[UTC]YYYY0MM0DD0hh0mm0ssXXX">>   see and this
• Use a button to setfield
• Use the Date Picker Plugin http://kixam.github.io/TW5-datePicker/

Try this trick if you want to accept simple formatted dates

<$edit-text field="date-field" field="myconfig" type="date"/>

But then you would be wise to convert these to tiddlywiki date/time serial number to make full use of the days operator and more such as comparing with a system date or today.

Just ask if you come across some gaps!

It is my considered view if you are using javascript functions in tiddlywiki rather than its existing methods

• You are doing it the wrong way
• You have discovered a gap that should be considered as a new feature or a plugin to be developed for the community.

Regards

Tony

[grundyunderhill]

Thanks Tony!  I appreciate you taking time to answer a post from a relative newcomer in the forum!

Your answer gave me some food for thought...  Any of the built-in filter operators which perform date calculations must allow for both timestamp strings (such as returned by <<now "[UTC]YYYY0MM0DD0hh0mm0ssXXX">>) and actual Date() objects (such as the "modified" or "created" field values), same as mine does.  So I looked at code for the "days" operator and saw there is a built-in utility function ($tw.utils.parseDate) which transparently handles either case.  Not exactly what I was seeking, but very helpful nonetheless!

As for your view on JavaScript....  I can partially agree :)  I too prefer using built-in functionality whenever feasible.  But on the other hand, somebody has to write those community plugins, right?

peace,

Nutt

[TonyM]

Mutt

Great to have you in our community.

I encourage you to write plugins however not for things that can already be done unless it does so much better. Sooner or later I will finish my JavaScript lessons and write them myself. But I would first target any gaps I see. I have consciously remained in the tiddlywiki environment using and "critiquing" its capabilities. I have being involved in many of the improvements but having not submitted github changes do not appear in the acknowledgements. I tell you this to say I eric, Mat, Mark, mario, Jed and others including our venerable leader Jeremy can help you use the existing tools and are most likely to detect gaps, although anyone is capable and we love new and interesting ideas.

If you want to write JavaScript I could announce a few ideas.

All this is to say we can handle timestamps already quite well but improvements are welcome especialy if they help newbies.

We are a productive community and working together seems to make every release expand tiddlywiki capabilities massively but there is also a lot of innovation on top of the stable releases in macros, techniques and plugins.

Regards
Tony

[Mark S.]

Tony's already explained how you can populate a new field with the special format TW uses for dates. So you

could populate a field yourself, and make the reasonable assumption that if the field is empty it doesn't contain

a date. What exactly did you want to do with your own date field?

That said, the tool kit for date handling in TW is really sparse, which is frustrating. For instance, there's no mechanism

for subtracting two dates.

As a newcomer, you might wantto know about the tiddly toolmap:

https://dynalist.io/d/zUP-nIWu2FFoXH-oM7L7d9DM#q=date

This is one of the most comprehensive listings of the tools, plugins and kit available for TW.

If you go there and plug in "date" in the search field, you'll likely find that others have already been putting together

date tools that you might find helpful.

TW's internal date stamps have other limitations. Like they only start in the 19th century, so aren't very useful for

historical work. I've started on some date algorithms that use no javascript and work with dates in human readable

format, like 2020-04-17 :

https://marxsal.github.io/various/playground.html#Create%20a%20range%20of%20dates

They can do things like calculate the number of days between dates. There hasn't been much enthusiasm expressed for them,

but eventually I'd like to expand their abilities.

Good luck!

[TonyM]

Mark

I am enthusiastic about your filling the gap here with date calculations its good work. However since I started using timestamps and the days operator to list aging tiddlers I have not needed your tools so far. A version of your tools is however needed perhaps even in the standard distribution.

Unfortunatly good work does not always get the feedback it deserves in the tiddlyverse.

Regards
Tony

[grundyunderhill]

Hi Mark,

Appreciate your response too!  Turns out the question you ask of me in your first paragraph, you've answered yourself in the 2nd: I'm writing a custom filter operator which calculates the difference between "now" and the date value of a field given as operand -- as you put it, subtracting two dates.

One of the first things I noticed when starting to play with it, is that custom fields populated in the way Tony describes behave somewhat differently than the built-in "modified" and "created" fields.  Even if populated with the prescribed format, custom fields still return a string value, whereas the built-in ones return an actual Date() object.

I guess we can call it a quirk rather than a gap, since it's pretty easily worked around.  But I got curious about whether I might be missing something obvious, if maybe there was a way to make custom fields behave like the built-in ones.

All that said, thank you for the links -- I'll be examining your non-javascript date-handling solutions with keen interest when I find time!  And no doubt the toolmap will be a great resource too.

Peace,

Nutt

[TonyM]

Nutt

Yes modified and created behave differently when transcluded etc... I don't believe this mechanisium has being documented. They are also rightfully excluded from edit in the edit template. It is however possible for you to do this with other fields.

For custom dates we use the view widget and the date or relative date parameters to display dates and there we choose the format as desired as you can with created and modified as well.

Relative date is a user friendly form of days to today but not so helpful for code.

When updating a date field It is possible to turn timestamp off so modified does not update.

A good standard is to save dates with utc in the format if a user outside your time zone is going to use your wiki.

Regards
Tony

[grundyunderhill]

Thank you Tony!  Good to know!