Timestamps in shared spans

Span.timestamp is problematic when misreported, or never reported. This issue will track known active zipkin libraries towards effective timestamp practice.

Summary of timestamp and duration logic

From http://zipkin.io/pages/instrumenting.html, the simplest logic for v1 format is:

unless (logging "sr" in an shared span) {
 set Span.timestamp and duration (both in microseconds)
}

When a server joins a span from incoming headers, it is sharing the span with
the client (who generated the headers). In that case, the server shouldn't
set Span.timestamp or duration since its view of the span is later and shorter than
the client.

Otherwise, you should set timestamp and duration on finished spans. That makes
sure indexing and duration queries work best.

Note v2 format includes a shared flag which is used to help with this problem
in v2 format, you always set timestamp and duration.

Status

Here are the status options for Span.timestamp/duration:

• unsupported: the library never sets Span.timestamp/duration
• always: the library sets Span.timestamp/duration even when it shouldn't
• supported: the library sets Span.timestamp/duration only when it should

This is a list of zipkin libraries and their status in supporting Span.timestamp/duration

See #46