Updates on use of Interval type attributes

There has been some recent confusion on use of Intervals-type attributes and doing date arithmetic. As a result, and following further testing I’ve updated my article Interval Data Type.

Some notes on items still unresolved:

  • Unless confirmed otherwise by @eastgate, assume it is not safe to add a duration (as an Interval or literal string) to a Date-type attribute that has a value of never. suggested best practice is to set a date before doing date and or time arithmetic. If necessary, in action code, test the attribute has a non-default value before doing any modifications.
  • Intervals have no published upper limit. However, given that the only allowed units of duration allowed in setting an interval are days/hours/minutes/seconds, and as a month contains varying numbers of days, the sensible user will restrict themselves to using Intervals of days or less. Again @eastgate may be able to clarify actual hard limits.

I think you can have long intervals. The original use case involved lengths of tracks in a concert recording, and so the accessors are those one might expect from that case.

The result of adding an interval to never is currently undefined. I suppose it would be better to have the result be never?

I think “never” makes more sense.

I’ve also got to the bottom of the initialise-and-alter-in-one-action problem. Let’s assume $StartDate is “never”, this (in the style of an earlier user example) fails:

$StartDate = date("15/08/2022" + "1 day");

But this works:

$StartDate = date("15/08/2022 + 1 day");

as does

$StartDate = date("15/08/2022") + "1 day";

This fails - in part:

$StartDate = date("15/08/2022") + date("1 day");

in that the initial date is set but the extra day increment is not added. IOW, date() must not be used for added or subtracted periods (e.g. “1 day”).

In updating notes today on intervals I did not that older date arithmetic duration markers from those used in Intervals (e.g. ‘d’ for day in the latter. I suggest that whether edge case parsing allows that the recommended date/time duration descriptor usage be unified for Date and Interval type attributes. This would reduce guess work for the new or occasional user of such features.

As part of considering dates and times, it would be useful if there were a Date.time() read/write method that either returned “hh:mm:ss” of the Date or set it using a string in format “hh:mm:ss” (possibly also allowing an alternate comma-delimited number list i.e. hh,mm,ss.

It would also be useful to have a keyword similar to ‘today’ but which sets todays date but no time (i.e. 00:00:00).

is equivalent to

$StartDate = date("15/08/20221 day");

You need a space character!

BTW, my use case for this is to pull timestamp markers from Adobe premier into Tinderbox and then create a clickable index for YouTube videos. The time stamp that comes from the Premier file is “00:00”, .e.g 01:36, for one minute and thirty-six seconds or 00:00:00, e.g. 01:05:22, for one hour five minutes and twenty-two seconds. I’ve been really struggling added dates and times with at $Timestamp interval imported in.

and

Ah, so my example should be:

$StartDate = date("15/08/2022" + " 1 day");
///                                ^ leading space added!

This avoids the unintended run-on @eastgate has spotted. If still not clear to the reader what’s happening, I could instead have written:

$StartDate = date("15/08/2022") + " " +"1 day");

BUT the result, i.e. with space,

$StartDate = date("15/08/2022" + " 1 day");

still fails as the result is a date of 15/08/2022 12:00 rather that 16 August at local time. The issue is not the space but the missing + inside the date() argument. So this works:

$StartDate = date("15/08/2022" + " + 1 day");

essentially generating the same argument input as:

$StartDate = date("15/08/2022 + 1 day");

However, if the ‘1 day’ is actually a calculated value then care is needed. I’ll address that in my next reply.

1 Like

As you’ll note I’ve updated my notes on the Interval attribute data type which should clarify the syntax.

If you type/paste 01:10 value into an Interval attribute in Get Info or Displayed Attributes, e.g. your $Timestamp attribute, you are setting a valid interval of 1 minute and 10 seconds. To set the same via action code use:

$MyInterval = "01:10";

For nuance of using day or hour elements in the interval, see my article linked at the start of the post.

To advance a date(/time) value (i.e. in a Date date type attribute or variable) you add the Interval without _ a date() wrapper. this is because Tinderbox knows Interval data is already (under the hood) a duration in milliseconds that it can use with a Date. Thus:

$StartDate = $StartDate + $Timestamp;

Or in newer syntax:

$StartDate += $Timestamp;

To move time backwards either subtract a positive duration

$StartDate -= $Timestamp;

or add using a negative interval:

var:interval vTime="-03:00:00";
$StartDate += vTime;
// sets $StartDate 3 hours earlier

Depending on your degree of automation, the latter may prove more useful allowing the same code to correctly handle additions and subtraction of time. In the above case vTime might be set using value generated by some other code and might be a positive or negative duration.

Leaving aside the already reported issue of working with as-yet undefined Date attributes (so for now, always set a date—any sensible date!—before use), changing durations at whole day or month/year scope should be done with date arithmetic. To add 4 days to $StartDate:

$StartDate = date($StartDate+"4 days");
or
$StartDate += "4 days";

There are some subtleties here as regards usage, depending on where the data is to be passed. A common ‘quick’ test is to run a stamp on a Displayed Attributes value and show the value in $Text. But, consider using a another Date attribute instead:

// assume $Start date is 15 Aug 2022 at 00:00:00
$Text = $StartDate+"1 month"; // gives '1663196400'
$TestDate = $StartDate+"1 month";  // gives'15 Sep 2022 at 00:00:00'
$Text = date($StartDate+"1 month"); // gives '15 Sep 2022 at 00:00:00'
$TestDate = date($StartDate+"1 month");  // gives'15 Sep 2022 at 00:00:00'

Thus use of $Text (or a String attribute such as my string) and silent auto-coercion of data type may lead the user astray when testing. In all four cases above the correct date resulted but in one case the lack of a date() wrapper caused the raw millisecond count to show and thus suggest an error where none had really occurred.

1 Like