[BUG] secondstoTimestamp not working correctly in 4.2

[sackboydad]

Make sure you're on the latest stable or beta build

• I have tested this on the latest stable or beta release

Is this a bug in companion itself or a module?

• I believe this to be a bug in companion and not a specific module

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

The SecondsToTimestamp function does not seem to be working correctly in v4.2. in v4.16 if I used SecondsTo Timestamp(385786) - or a variable that equals 385786 - it would return 107:09:46. However, if I use the exact same function in v4.2.3 it will return 11:09:46. This also happens on the current Beta of 4.30+8842 MacOS 26.2.

We use this all the time to calculate how many seconds from now until Sunday at 10:56:43. It's like the secondstotimestamp function can't handle more than 24 hours any more.

Steps To Reproduce

No response

Expected Behavior

No response

Environment (please complete the following information)

- OS: MacOS 26.2
- Browser: Safari
- Companion Version: 4.23, 4.30+8842

Additional context

No response

[thedist]

I believe it was this PR #3668 by @alex-Arc where the function was updated with new functionality but it is a breaking change so it is going to mess up a lot of peoples setups unfortunately.

If you check out the docs for secondsToTimestamp you can see how to provide a format string to have it display days as well, for example secondsToTimestamp(385786, 'd:hh:mm:ss') would show 4:11:09:46. Or you could split it up into 2 functions and display 4 days 11:09:46 or something like that.

It's not a breaking change I agree with, but it got merged so you may need to either change to working with the new formatting, or write an expression yourself that will parse the seconds to 107:09:46.

[alex-Arc]

Yeah i do see that this could be annoying
Can we conceive of a formatting expression to help this?

Maybe dhh would not include day overflow and hh would not

Something in that direction?

[sackboydad]

Yeah i do see that this could be annoying Can we conceive of a formatting expression to help this?

Maybe dhh would not include day overflow and hh would not

Something in that direction?

You probably weren't addressing to me (the person that initially wrote), but I think this would work. And I like the choice of the old way and the new way.

[alex-Arc]

Don't know if we could come up with a better lettering

An a second thing would be if it should be generic so that minutes also could be the largest unit

[Julusian]

My first thought was hhh for the unlimited form, which could also exist for any other unit too. that kind of follows the usual conventions of these kinds of formatting, of more letters meaning longer formatting

But I havent done any research into whether that could cause further issues/clashes

[alex-Arc]

I do like that it feels cleaner

It colides a bit with this form the milliseconds

• S / SS / SSS - milliseconds, in varying levels of accuracy

And i would say that it is common to see hh meaning do some zero padding and h has no padding
But we don't have that currently

[alex-Arc]

I looked it up and we do have the padding functionality.

companion/shared-lib/lib/Util.ts

Line 33 in d937e10

result = result.replace('dd', pad(days, '0', 2))

companion/shared-lib/lib/Util.ts

Line 43 in d937e10

result = result.replace('d', days.toString())

what about adding an extra parameter to the function like

secondsToTimestamp('nHH:mm:ss', 61473285408397, 'hour')

to denote the larges desired unit?

[arikorn]

I just asked Google and its "regular" AI about hhh and it didn't like it but says to use brackets instead:

To display hours greater than 24, the custom format code generally needs to be [h] or [hh]

The requirement to display hours that exceed 24 (e.g., for a total duration) is common and typically achieved using square brackets around the hour format code in various software, most notably Microsoft Excel.

or more generally:

Over 24 hours: [h]:mm:ss or [h]:mm (or [hh]:mm:ss)
Over 60 minutes: [m]:ss
Over 60 seconds: [s]

I've tested and can confirm it works in Excel. I recall that @dnmeid had previously advocated for Excel style formatting in one of my issues, so this could be a step in the right direction.

[alex-Arc]

not a bad idea, but maybe a bit hard to implement, might need som regex magic.

what would be the expected result if the user adds brackets to two units?

[arikorn]

Well Excel treats it as an error -- it just doesn't allow it, -- so you can too. And [d] is an error too. Likewise [xx] anywhere but the first position is refused. (As an aside/exception, Excel allows d:[hh]:mm:ss, but gives the wrong value, so that's really still an error,)

You don't need any regex the way you're doing it, just some error checking and doing things in the right order.
For example,

• if the format contains '[' but doesn't start with '[' throw an error (or return without processing?)
• if the format contains two or more '[' or two ']' throw an error
• otherwise just replace '[hh]', '[mm]', '[ss]' before replacing 'hh' 'mm' or 'ss', etc.

So yeah, it's another 10 lines that way but there's no way around it, since the return-values are all different. Alternatively, look into the library Dorian mentioned in the comment I linked above.

Are you throwing errors in the current code if the format string contains invalid characters? Perhaps the original behavior was not to? Regardless, you can choose how to treat the first two cases: (1) just give the user what they asked for (2) return w/o processing or (3) throw an error.