Switch SpanEvent times to use time.Time

[MrAlias]

Use time.Time, a timestamp, to identify the start and end time of the SpanEvent instead of representing them as nanoseconds since boot time in a built-in int64.

This is motivate by the need to support things that report timestamps for start/end times directly. Things like the custom SDK (see #1045).

To support the conversion for probes, the utils.BootOffsetToTime function is added. This converts between the measured nanoseconds since boot-time that an eBPF program measures, and a timestamp.

The inverse function, utils.TimeToBootOffset, is also added to facilitate testing.

[RonFed]

LGTM, if there is a way to call this conversion in the generic probe so we can do it in one place it is better but I don't have a strong opinion about it.

[MrAlias]

if there is a way to call this conversion in the generic probe so we can do it in one place it is better

All of the convertEvent functions are converting a probe specific event type. I don't think there is a more generic way to make this conversion than with the provided functions.

[RonFed]

if there is a way to call this conversion in the generic probe so we can do it in one place it is better

All of the convertEvent functions are converting a probe specific event type. I don't think there is a more generic way to make this conversion than with the provided functions.

My point was that before this change the conversion was done in one place (the controller) and now it is duplicated across all the probes. As I said I don't have a strong opinion about this.

[MrAlias]

Understood. Keep in mind, with the addition of the SDK not all events are going to report time as an offset from boot-time. This change is made to support that addition.

This also means there is not going to be a generic way to handle all event times given they would be timestamps or offsets from boot-time.

I see it as preferable to unify on using timestamps, as proposed here, and convert the boot-time offsets so when we allow users to send us data¹ they can rely on standard Go types and time measurements.

Footnotes

1. Custom Probes #1105 ↩