I tried cheating the system by making up event markers in the rinex file and putting them after the header and before the first epoch. no result.
I then tried putting all the markers after the first epoch. from memory it processed the first or last one only and ignored the rest. The result was a pretty wild position as, I assume, it did an interpolation (linear?) in time, using the adjacent measurements.
I then tried spacing the markers one after each of the first few measurements. so it was meas, marker, meas, marker, meas, marker, meas, meas, meas… All events processed, but as before, the wildness of the solutions seemed to be based on how close in time the event marker was, or wasn’t to the adjacent measurements.
For me, my ideal would be to take a list of my recorded events from the events.pos file, offset the event times by -0.25 seconds, and put these back in the rinex file in their proper chronological order. If you know your logging rate then you know the exact measurement record immediately following or preceding the spot where your new measurements are supposed to fit in.
Your script would definitely need to move the event markers by either 2 or 3 measurement blocks. 2 if the event is more than 0.05 seconds from the previous measurement epoch, and 3 if it is less than 0.05 seconds from the previous measurement epoch. That is the combination of my 0.1 second logging rate and -0.25 second needed time offset.
I would be willing to make a donation to that foundation. I do have an excel solution, but event positions straight from RTKPOST would make life easier. Could the script accommodate a prompt for time offset if it turns out my -0.25s needs refinement?