Eric, Don't bother here, but a simple flag to detect a data change between start and end may be sufficient here. Basically a separate calculation for such "date transgressions" could do it, but it would be well served by having the actual start/end date collected as well. One could even count the number days between (With calendar utility perhaps leverage the days operator) for a full elapsed time calculator. Such a method should be immune from other calendar artefacts because the days should be appropriate from a calendar utility.
Just adding Tony On Monday, June 22, 2020 at 10:52:55 AM UTC+10, Eric Shulman wrote: > > On Sunday, June 21, 2020 at 5:42:24 PM UTC-7, TW Tones wrote: >> >> This has some cute code patterns in it, like second padded field. Love >> your work. >> Before delving in, in detail have you accounted for tasks active across >> midnight? >> > > Yeah.. it should handle day boundaries just fine... but it will have > problems if you cross a *month* boundary. > > I punted on that since the number of seconds in a month varies because > months have different number of days > and I didn't want to implement a lookup table to handle it. It gets even > more complicated if you want to account > for leap years. > > But it should work properly as long as you a task is not active at > midnight at the end of a month. > > -e > -- 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/6632374c-51ae-431f-a8d7-5f1752fd5cf0o%40googlegroups.com.
