Consider adding ntp functionality to periodically query clock offset and adjust span starttime/endtime

[Frefreak]

Problem Statement

Maybe this should be asked in the specification repo instead but since we're experimenting our proposed idea in go sdk, it might be ok to post here first and gather some thoughts. Currently un-synchronized time clock among clients may cause trouble when displaying and calculating network time of API calls. This does not only happen in browsers but can also happen sometimes in other languages if in badly configured environment. In some cases the sysadmin can try to make different hosts' time clock synchronized via programs like ntp, but there're cases where we simply can not (for example running in a restricted environment where we don't have a say about the underlying system).

Proposed Solution

Similar to the idea of this javascript sdk issue, we propose a solution to embed a simple ntp client in the sdk with a clock offset variable. The basic idea is that sdk user can optionally configure a ntp server and a querying interval when initializing the trace provider, which will spawn a goroutine to periodically query the ntp server and update the clock offset variable. During span creation and end sdk can query this clock offset and add to time.Now() to make an adjusted time, which can ensure different hosts configured with the same ntp server to have a consistent time clock.

example use cases:

	tracerProvider := sdktrace.NewTracerProvider(
		sdktrace.WithSampler(sdktrace.AlwaysSample()),
		sdktrace.WithResource(res),
		sdktrace.WithSpanProcessor(bsp),
		sdktrace.WithNTPConfig(
			ntp.NewConfig("some ntp server").WithVerbose(true).WithInterval(5 * time.Second),
		),
	)

If not configured, everything should behave like before (except some check during provider creation).

[MrAlias]

Thanks for your interest in the project and the suggestion. The coordination of distributed system's time keeping is something beyond the scope of this project.

That said, it seems reasonable to provide a more generic Clock kind of interface that the TracerProvider could then use. This would be similar to what is done in the metrics proof-of-concept controller. That way you would be able to provide a clock that satisfied your coordination scheme.

[Frefreak]

Thanks for the response. Providing a Clock-ish interface seems like a good idea. I can try to implement this and see how it goes.