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 On Friday, April 17, 2020 at 11:25:05 PM UTC-4, Mark S. wrote: > > 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! > > On Friday, April 17, 2020 at 3:51:01 PM UTC-7, grundyunderhill wrote: >> >> 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 >> >> On Thursday, April 16, 2020 at 10:35:33 PM UTC-4, TonyM wrote: >>> >>> 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 <https://tiddlywiki.com/#Date%20Fields> and this >>> <https://tiddlywiki.com/#now%20Macro> >>> - 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 >>> >>> >>> On Friday, April 17, 2020 at 12:01:35 PM UTC+10, grundyunderhill wrote: >>>> >>>> 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 >>>> >>> -- 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/423706ab-5115-4393-a154-7846436c38a6%40googlegroups.com.
