fix: span duration property has inconsistent time formats

[mkultraWasHere]

Bug Fix - span.duration() has inconsistent timestamp format

The Problem

end_time = self.end_time or time.time()
return (end_time - self.start_time) if self.start_time else 0.0

self.start_time and self.end_time come from OpenTelemetry and are in nanoseconds
time.time() returns seconds

When the span is still running (self.end_time is None), the fallback time.time() returns a value ~10⁹ times smaller than self.start_time, producing a negative or nonsensical duration.

Example

self.start_time = 1733000000000000000  # nanoseconds (2024 timestamp)
self.end_time = None                    # span still running
time.time() = 1733000005.0              # seconds

end_time = self.end_time or time.time()  # = 1733000005.0 (seconds)
duration = 1733000005.0 - 1733000000000000000  # = -1.73e18 (WRONG!)

---

Generated Summary:

• Updated the duration calculation in the Span class to use time.time_ns() instead of time.time().
• Changed the return value of the duration to be in seconds by dividing the nanoseconds result by 1e9.
• Added a check for start_time early in the duration method for better clarity.
• These changes improve precision in span duration calculation, potentially impacting timing and performance analysis within tracing.

This summary was generated with ❤️ by rigging

[Copilot]

Pull request overview

This PR fixes a critical bug in the Span.duration() method where mixing time formats (nanoseconds from OpenTelemetry vs seconds from time.time()) produced incorrect negative durations for active spans.

Key Changes:

• Replaced time.time() with time.time_ns() to maintain consistent nanosecond precision
• Added division by 1e9 to convert the nanosecond result to seconds as documented
• Refactored the early return logic for better code clarity

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.