Add convenience functions

[darbyjohnston]

Summarize your change.

Add a few convenience functions:

• Add a TimeRange constructor that takes three doubles; the start time, duration, and rate. This allows you to construct a TimeRange like: TimeRange(0.0, 48.0, 24.0), which is a bit more convenient than: TimeRange(RationalTime(0.0, 24.0), RationalTime(48.0, 24.0)).
• Add RationalTime::is_valid_time() to complement RationalTime::is_invalid_time(). This can be a bit easier to read: if (time.is_valid_time()), instead of: if (!time.is_invalid_time()).
• Add TimeRange::is_invalid_range() and TimeRange::is_valid_range() to match RationalTime.

Small fix:

• Remove explicit from TimeRange constructors. The explicit keyword only needs to be used with constructors that take a single argument.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.80%. Comparing base (c0e97b0) to head (f85a028).
Report is 39 commits behind head on main.

❌ Your changes status has failed because you have indirect coverage changes. Learn more about Unexpected Coverage Changes and reasons for indirect coverage changes.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1825      +/-   ##
==========================================
+ Coverage   84.11%   84.80%   +0.69%     
==========================================
  Files         198      176      -22     
  Lines       22241    12745    -9496     
  Branches     4687     1181    -3506     
==========================================
- Hits        18709    10809    -7900     
+ Misses       2610     1758     -852     
+ Partials      922      178     -744     

Flag	Coverage Δ
py-unittests	84.80% <100.00%> (+0.69%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/opentime/rationalTime.h	95.83% <100.00%> (+1.15%)	⬆️
src/opentime/timeRange.h	98.30% <100.00%> (-0.79%)	⬇️
...lineio/opentime-bindings/opentime_rationalTime.cpp	94.87% <100.00%> (+0.27%)	⬆️
...imelineio/opentime-bindings/opentime_timeRange.cpp	98.07% <100.00%> (-1.93%)	⬇️
tests/test_opentime.py	99.75% <100.00%> (+<0.01%)	⬆️

... and 124 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 98840ac...f85a028. Read the comment docs.

[meshula]

good additions, some requests

[meshula]

thanks for the update!

[jminor]

I had to think for a moment about the duration<0 check... To be clear, it should be fine for a RationalTime to have a negative value (e.g. when subtracting two times a-b you might get positive or negative result) but I think it is good to constrain a TimeRange to have a non-negative duration, so that any code using ranges can assume the start is before the end.

[darbyjohnston]

What do you think about having invalid time and range member variables? That way you can use them to initialize values like this:

RationalTime t = RationalTime::invalid_time;
...
if (t.is_valid_time())
{
    ...
}

Which I think is a bit more readable and consistent than constructing invalid times manually.

There is an _invalid_time member in RationalTime, but it's currently private.

[jminor]

I'm a little hesitant about that since people might think if (myTime == RationalTime::invalid_time) { ... } might be equivalent to if (myTime.is_invalid()) { ... } but it won't be the same since the specific value/rate values might differ in how they are invalid.

[darbyjohnston]

That's a good point. I find the == operator for RationalTime is already a bit tricky since it rescales the rates, which is not always what I expect.

[meshula]

Equality versus strict equality, both are useful...