They said they are not gonna fix this :(
(and that we should calculate with ticks, which feels like a dirty hack, and you still have to handle the wrong precision)

I ran into a similar issue. A small test case:

Use a 59.94 fps clip

Calling the ExtendScript

clip.getMarkers().createMarker(10 * 1001 / 60000) // ExtendScript
clip.getMarkers().createMarker(20 * 1001 / 60000)
clip.getMarkers().createMarker(30 * 1001 / 60000)

Results in the markers:

{"end":{"seconds":0.16683333333333,"ticks":"42378336000"},"start":{"seconds":0.16683333333333,"ticks":"42378336000"}}
{"end":{"seconds":0.33366666666667,"ticks":"84756672000"},"start":{"seconds":0.33366666666667,"ticks":"84756672000"}}
{"end":{"seconds":0.50049999999606,"ticks":"127135007999"}, "start":{"seconds":0.50049999999606,"ticks":"127135007999"}}

The first two are good. The third is offset by 1 frame or 1 tick.

I’d expect the code as simple as above to just work fine. The Marker API should allow to provide start/end time also in ticks.

Another test Case with the Time API:

var t = new Time(); // ExtendScript
t.seconds = 0.5005; // (30*1001)/60000

Once set, seconds will become 0.50049999999606.

0.50049999999606 doesn't seems to be the nearest floating point number for 0.5005 in double or single precision, and seems to be rather the rounded result of the division of 127135007999 by 254016000000.

So the Time API seems to be an error source. But decimal arithmetic in ExtentScript seems to be precise. A test case :

var t = 0.1 + 0.2; // ExtendScript
t.toPrecision(20);

gives:
0.30000000000000000000

The same code running in Chrome gives:
0.30000000000000004441

I can confirm this bug for PPro v14.5 with new world on and off on windows 10.

"that does not work" :

I didn't test (I'm working with Panel and JSX but not with markers), but I just know that for in/out points for example in the timeline, an exception is raised but it works ! (So for in/out points you just need to call the line under try catch and it does the job).

So when you said that it didn't work, is it because you had an exception or because the marker didn't change its location ?

Hey,
thanks for commenting! :)

``marker.start`` cannot be modified by setting a time object, that does not work.
``marker.start.ticks`` does not change, no matter what I set it to.

I could not find a workaround or a way to correct the marker timecode :(

p.s: lol markdown works in the bug description but not in the comments :D

Hello,

For me it seems to be a precision issue. You should not set Times with seconds but with Ticks. (I know you said that setting Ticks did nothing, but you should keep trying in this direction).

The "createMarker" functions only takes float in input, so we need another workaround.

Create your marker with the seconds you want (so there will be your error), then get the Marker Object, and set the "marker.start.ticks" attribute of it (it needs to be a string !). If it doesn't work, try to create a "Time" object, then set the ticks, and write marker.start = myNewTimeCreated.

8.35999965667724609375 is the closest float to "decimal 8.36".

But I had the exact issue of loosing 1 tick when getting markers in AfterCodecs. And had the same strange behavior I could move the marker 1 pixel ahead without changing the frame it is on

I had the exact same problem