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 ??
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
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.
@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.
I would like to use the standard to set the field to [UTC]YYYY0MM0DD0hh0mm0ss0XXX
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.
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.
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.