Hi ,
quick question , which i think i already know the answer to , but just checking in case i missed anything
the date picker plugin does not allow assigning an action widget to it , so i cant assign an action that would trigger in setting or changing a date ??
Hi,
The date picker plugin is very outdated, you should use @EricShulman’s edit-date macro:
https://tiddlytools.com/#TiddlyTools/Time/EditDate
AFAICT it doesn’t provide actions though.
Depending on your needs, you could also try the <$edit-text> widget:
\define myActions() <$action-log actionValue=<<actionValue>>/>
<$edit-text field="mydate" type="date" inputActions=<<myActions>>/>
Fred
Thank you ,
exactly what i wanted 
I use <$edit-date field="lastSync" showTime="yes" showSeconds="yes" use24hour="yes"> widget
from "$:/plugins/kixam/datepicker"
I’ve just updated TiddlyTools/Time/EditDate to add support for the inputActions parameter.
You can get the update at the link shown above.
enjoy,
-e
Now this is responsiveness! Thanks!
thank you all for your help
sorry to reopen this conversation , but i have only gotten to use the edit date macro today,as i now need to control the date format ,which is something i cant do using edit-text
but i dont know what i am doing wrong ,
\define myaction() <$action-setfield field="ABC"/>
<$macrocall $name="edit-date" field="mydate" inputActions = <<myaction>>/>
shouldnt this trigger the action ?
This says to set the field ABC to ?
There is a minor syntax error in your macro usage: you can’t put spaces between a macro parameter name and it’s value. Thus, you must use: inputActions=<<myaction>> rather than inputActions = <<myaction>>
The TiddlyTools <<edit-date>> macro uses an <$edit-text> widget with a tiddler param that points to a temporary input tiddler with a name like this: $:/temp/TiddlyTools/edit-date/TiddlerName/FieldName, where “TiddlerName” is the actual target tiddler title and “FieldName” is the field name within that target tiddler.
As a result, when the inputActions are triggered, the “currentTiddler” title that is being used is the above temporary tiddler. Thus, your myaction macro is setting field="ABC" within the temporary tiddler, rather than the target tiddler param that was specified by the <<edit-date>> macro (or the current tiddler in which the <<edit-date>> macro occurs if no tiddler param was specified).
I have just updated TiddlyTools/Time/EditDate so it will automatically set the “currentTiddler” to the correct target tiddler before invoking the inputActions. This should fix your problem.
Get the update here:
https://tiddlytools.com/#TiddlyTools%2FTime%2FEditDate
Let me know how it goes…
enjoy,
-e
<$action-setfield field="ABC"/>
is valid usage, and is equivalent to:
<$action-setfield $field="field" $value="ABC"/>
Thus, the $action-setfield widget in @paulgilbert2000’s example code is being used to set a field named “field” to a value of “ABC”.
-e
Thanks again, , new version works as expected!
i should have used a more clear example , it was a confusing one, sorry
@EricShulman I wanted to use your edit-date macro to set times/date to the tiddlywiki serial number and it does not seem to make use of the format parameter.
Thanks in advance
Hmmm… it’s a bit complicated…
The first issue is that the <<edit-date>> macro has several ways to determine the desired date/time output format:
If you don’t specify a format:"..." macro parameter, a built-in default format of YYYY/0MM/0DD is used.
If you do specify a format:"..." parameter in the macro call, the indicated format is used each time you pick a date from the popup.
You can also enter a desired format into the format input field displayed in the calendar popup. However, that format is only applied temporarily for that single instance of the popup and the next time you trigger the popup, the format reverts back to whatever was specified by the format:"..." macro parameter (or YYYY/0MM/0DD if no format:"..." parameter was provided in the macro call).
Thus, to consistently use the TWCore 17-digit datetime format each time the popup is triggered, you should include format:"YYYY0MM0DD0hh0mm0ss0XXX" as a macro parameter.
Note how this format does NOT include the “[UTC]” prefix and that if your specfied output format does include the “[UTC]” prefix, then the resulting datetime output actually retains the “[UTC]” prefix, rather than removing the prefix and converting the time value based on the timezone offset for your locale.
This is because of how combination date+time output is constructed by the macro code:
By default, the <<edit-date>> macro only expects to output formatted date strings. If your desired output format includes time codes (e.g., 0hh0mm0ss0XXX), these automatically default to all zeros (‘000000000’) unless you specify the includetime:yes macro parameter.
Even so, the time value that is applied is always the current LOCAL time without applying any conversion to UTC time. This is done so that the formatted date output will always report the actual date you selected from the calendar, without regard to any UTC timezone offset that might result in the formatted date shifting forward or backward by a day.
For example, since you are in timezone UTC+10, if you pick a date when your current local time is before 10am (e.g., “2023/10/14 at 09:00”), converting to UTC would result in the output date being shifted backward to report the day BEFORE the date you actually selected (“2023/10/13 at 23:00”).
I MIGHT be able to update my code with special-case handling that performs actual conversion to UTC time values (with the potential date shifting as described above), but I need some time to experiment a bit to work out the details. I’ll let you know if/when I manage to accomplish this. In the meantime, I hope the above explanation of current implementation makes at least a little sense.
-e
I’ve just posted an update to https://tiddlytools.com/#TiddlyTools%2FTime%2FEditDate to improve handling of the [UTC] formatting prefix:
As before, if [UTC] is omitted from the date/time formatting syntax, then the current local time will be used in the output (assuming you have included time formatting codes in the formatting syntax (e.g., 0hh0mm0ss0XXX).
However, if you DO use the [UTC] prefix, then any time formatting syntax will now use the current UTC time value (i.e., adjusting for your timezone offset). Note however, that this has no impact on the date portion of the output, which will always reflect the actual calendar date that you clicked upon, even if adjusting for UTC time offsets would otherwise cause the date to be shifted forward or back by a day.
Also, the includetime:yes macro parameter is now obsolete. Instead, you can just use (or not use) time formatting syntax as desired, without needing to specify the includetime:yes parameter. If you want to generate a complete 17-digit system timestamp without including the current time value, just include 9 hard-coded zeros to pad the time portion of the output format (e.g., YYYY0MM0DD000000000). Alternatively, you can use 120000000 (“midday”) to pad the time portion which will generally avoid any issues with “date shifting” due to timezone offsets since all timezone offsets fall in the range from -12 to +12.
@TW_Tones: give the new code a try and let me know if it works better for your purposes.
enjoy,
-e
Another update to fix UTC vs local timezone offset calculations that resulted in incorrect dates when the offset crosses a date boundary (i.e., midnight).
I’ve also refactored the documentation into a separate “/Info” tiddler, so that you can install the <<edit-date>> macro without including the extra overhead of the documentation.
https://tiddlytools.com/#TiddlyTools%2FTime%2FEditDate
and
https://tiddlytools.com/#TiddlyTools%2FTime%2FEditDate%2FInfo
enjoy,
-e