Allow explicit start/end timestamp for Span

[carlosalberto]

In order to support a OT bridge, we need to support explicit, optional values for start/end timestamp.

[SergeyKanzhelev]

In Open Census explicit start/end is only allowed for SpanData creation, not for a span. Overriding start and stop may result in inconsistent timing inside the span when start time is not aligned with message events and annotations inside it.

Would creation of SpanData work better for this scenario? Which scenarios would break and are those important for end users?

[carlosalberto]

Overriding start and stop may result in inconsistent timing inside the span when start time is not aligned with message events and annotations inside it.

Correct, this is something the user has to take care of, in case he overrides that - sadly this is something we need to support, backwards-wise, for OT.

[SergeyKanzhelev]

sadly this is something we need to support, backwards-wise, for OT.

We can support a scenario when you construct an entire SpanData postfactum. Without even creating the Span. And pass it to the exporter. See how we do it in C#: https://github.com/census-instrumentation/opencensus-csharp/blob/2e9f34e452b04831ce65b5894748f8045fef77da/src/OpenCensus.Collector.StackExchangeRedis/StackExchangeRedisCallsCollector.cs#L115-L127

What will be broken if above scenario is supported, when below scenario of time modifications is not?

[tsloughter]

I like the construct entire SpanData postfactum idea. I had been struggling with how to support span creation for the Elixir database library Ecto which simply pushes events and this would allow to do that without any hassle. It means you won't have the SpanData available to modify by the database client but I don't think this is an issue at least for the time being.

[bogdandrutu]

I agree with @tsloughter and @SergeyKanzhelev. I think actually having the SpanData in the api, and on the Tracer have a "recordSpanData" (name can be better) makes more sense, because in case where we construct the Span from different events (source of data) api calls like addAnnotations (or log in OT) will have a wrong timestamp associated with that annotation/log (also if the implemenation of addAnnotation/log records extra informations like "threadid" with every log statement that will not be the correct threadid that recorded the event).

[SergeyKanzhelev]

census-instrumentation/opencensus-specs#255

[carlosalberto]

Not against using SpanData, but I'm wondering if that will mean putting too many implementation details in the API ;)

[bogdandrutu]

Proposal: Try to see how SpanData + Report API would look like.