[Interval].format() is an operator; it takes an interval and returns a string. So you might say
$MyInterval = $URL.extract("#t=(\d+)");
$MyString=$MyInterval("hh:mm:ss");
I’m still unsure what exactly the correct syntax is here:
$TimeCode = $MyInterval("hh:mm:ss");
or
$TimeCode = $MyInterval.format("hh:mm:ss");
?
I’ve tried both but the string is still returned in the format mm:ss, without the leading 00: for $MyInterval smaller than 3600.
Is $TimeCode an interval, or a string?
I have experimented with both, but neither produces the desired outcome.
It turns out there was a misunderstanding in my interpretation of use of .format() with Interval type data. I’ve updated my article on Interval.format("formatString") accordingly.: see there for an explanation.
In short, to get an Interval as a string, just pass the latter to a string:
$MyString = $MyInterval;
So an interval of “01:32:14” would generate a string of … “01:32:14”.
Yes, this is what I experienced, that is why I suggested the transformation above.
I sense we’re going in circles. The issue wan’t that we weren’t getting the right result from coercing Interval data but why. This updated description hopefully resolves that issue. If it’s still unclear, please give context and I’ll try and make it better.
In context, the original problem raised two discrete issues:
- How to parse seconds to an interval. Several regex are proposed, all of which work in context.
- Passing data into and out of Interval data type.
Please correct me if I’m wrong, but I don’t think the question of how to display the leading zeros for hours where the number of seconds is below 3600 has been resolved. That is, whereas an $MyInterval value of 3600 is passed on as a string “01:00:00”, a value of 3599 results in a string “59:59” instead of the desired “00:59:59”.
I’ve address this in my updated article on Interval.format().
To restate, using .format() with interval data has limits. Essentially, is expects a value of 59:59 or less. For bigger intervals (> 59:59) you might want to use a different approach. The updated article already addresses the latter.
As the thread above shows, there’s no one single way to do this.In though cases
Interval does expose an underlying number, so whilst I understand the description, I think it is misleading you. IOW, and interval of “01:00:00” is that, even though you can think of it—via time mathematics—as 3600 seconds.
What you are fighting here is that whilst Interval can stretch as high as days (I’m not totally sure but I think 365 days is the limit), by concept is focussed on periods of less than an hour, thus the default “00:00” is “mm:ss”. If the duration is less than one hour, you can’t force an Interval-type attribute to use an “hh:mm:ss” format. You can use string manipulation, to prefix the Interval string with “00:” but you can’t do that unless you store the result as a String instead of an Interval.
Also, you can’t use Interval.format() to achieve the latter. The only date formatting strings usable with Interval.format() as l and L (upper- and lower-case letter L). In fairness the latter date formatting and we are formatting durations, albeit of time.
I sense there’s a feature request to make here, by someone with the actual need, for more formatting of interval strings. A grey area is whether we are just talking about how Interval look as Displayed Attributes or wider (re-)formatting.
Thank you, @mwra. Your patience is admirable. I had missed the full implications of your update to aTbRef9, but this is much clearer to me now. It looks like string manipulation will work just fine because I don’t require the value to be stored as an interval. There’s always the URL with the reference to seconds and hundredths of a second to fall back on if needed.
No problem, in investigating this I realised I’d mis-understood how .format() worked, specifically with regard to Interval type data. As a result I’ve been able to write a hopefully more useful aTbRef article, so we’ve all gained. 
It’s also made me realise that my page on the data type Intervalcould be improved as nowhere does it make plain that whilst Intervals can last for days, by design intent they were envisaged as sub-1-hour durations and thus the way they display be default and how come data-type coercions work in unexpected, if correct, ways!
Actually, I think this is not the case.
My understanding of the current situation is as follows.
$MyInterval.format("l")
returns a string version of $MyInterval, formatted positionally — days:hours:minutes:seconds.
$MyInterval.format("L")
returns a string version of $MyInterval, localized, using a more verbose form (e.g. “3 days 17 hours”)
Sadly not so, as these tests† show:
Notice how (as discussed above) ‘normal’ date formatting, as using the last test here does not work. No formatting occurs, the time only looks right because it is the same as the raw string of the Interval. The failure is shown:
Error, the OP wanted 00:04:30 but got 04:00.
There’s no foul here. The issue is just that how difficult it thus becomes to make an “hh:m:ss” render of an interval for 59 minutes or less.
As in reference to time “nn:nn” more often refers to 'hh:mm" not “mm:ss”, Interval’s default assumption of a default value/render of “mm:ss” is clearly confusing some users.
Anyway, not my problem, so not my fight. i’m simply trying to provide understandable documentation of the status quo. The appearance, if not the fact, is Intervals were originally designed as sub-hour durations. I thus assume (I don’t recall much of the arrival of this data type) the types scope was increased to day scope with a vendor-advised upper bound of 365 days.
This raises the question—which I can’t answer—of whether it unreasonable to want time duration (i.e. Interval) shown in a consistent format, i.e. 00:23:45 not 23:45. I don’t think there is a ‘right’ answer but getting the h:m:s form is harder than imagined.
†. I should add, I’m using a UK locale MBPro running macOS 12.6.1, lest locale be a factor.
I do wonder if part of the story here is having a $DisplayedAttributesIntervalFormat attribute. That said, if Intervals only support l and L date/time format codes, such an approach might be moot.
I’ve just revised and added to this article, Interval Data Type, to address some of the issues exposed above.
Hi Tilmann,
How are you getting the timecode marker using Hookmark?
Thanks
Tom
Hi Tom,
With Hookmark installed, grabbing the timecode marker (i.e. deep-linking to a specific passage in a video file) is currently supported by QuickTime Player (I’m not aware of other video players supporting this). When you are at a position you wish to bookmark/link to, invoke Hookmark (cmd-shift-space). I have set Hookmark up with Tinderbox as my preferred note taking app, so when creating a new note from Hookmark (cmd-n) it automatically creates a note within a folder “Inbox” in the active Tinderbox document, copying the deep link from Hookmark into the URL attribute of the Tinderbox note. Alternatively, you can copy the deep link in Hookmark to the clipboard (cmd-c) and use it in elsewhere.
I hope this answers your query.
Best,
Tilmann
1 Like
Thanks Tilmann. Ahh, I was trying hookmark with some of the Tinderbox vimeo videos. This explains why I was not able to get the timecode directly with hookmark.
Many thanks.
Tom