Implement PSR-20 Clock

[xvilo]

I was going through the repository and noticed that is a custom ClockInterface to handle time-related functionalities. As you might be aware, the recently released PSR-20 ClockInterface provides a standardized way to deal with time, and it might be beneficial to replace the custom ClockInterface with this new interface.

However, I noticed that the return types of the methods in the PSR-20 ClockInterface are not compatible with the current implementation. The current implementation returns an int, while the PSR-20 interface returns a DateTimeImmutable object.

Therefore, I propose a few ideas to resolve this incompatibility issue:

• Extend the current in-library ClockInterface with the PSR-20 interface. And rename the old method + usages, this way the old method can still be used while the standardized method can be implemented when possible. 

• Fully replace the interface with the PSR-20 implementation and update all references.

I believe that adopting the PSR-20 ClockInterface would improve interoperability and make the opentelemetry-php repository more standard-compliant. Next to that, it would be a great opportunity if this could be done before a full 1.0 release. I would love to hear your thoughts on this matter and if you plan to adopt the PSR-20 ClockInterface.

[brettmc]

Hello, as a rule, we're all for using PSR standards as much as possible throughout OpenTelemetry. I don't see why we wouldn't try to implement psr-20 as well (although it wasn't on anybody's radar, I suspect). If implemented, I'd rather see it completely replace the existing interface (option 2 above).

A couple of things to consider:

• otel timestamps are numeric with microsecond precision; it looks like DateTime does support this, but we'd need to confirm that we don't lose any precision this way over the current implementation.
• It would be nice if every usage of the clock didn't have to deal with knowing the DateTime format incantation to get epoch in microseconds, perhaps psr-20 implementation needs to be wrapped in a class to take care of that?
• unit tests of time-sensitive processes obviously still need to work

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[xvilo]

Still needs work

[timo-quentic]

Still needs work

Nope, sorry but ...

The PSR 20 Interface asks for a DateTimeImmutable: https://www.php-fig.org/psr/psr-20/

The Otel spec asks for a nanosecond precision time integer: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#time

which needs some work in php in the first place: https://github.com/open-telemetry/opentelemetry-php/blob/main/src/SDK/Common/Time/SystemClock.php

[xvilo]

Correct, my comment was there just to not have it auto closed with the stale label. I personally don’t have time to implement it, but it’s nice to have in the future

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[xvilo]

Still relevant

[brettmc]

Taking another look at this since I'm looking at our clock implementation at the moment.

The Otel spec asks for a nanosecond precision time integer

I think this is a deal-breaker for implementing PSR-20. Reading the psr-20 spec, the definition of time is:

The current time as an integer number of seconds since Jan 1, 1970 00:00:00 UTC

That's nowhere near enough precision for OpenTelemetry's purposes, by many orders of magnitude. The most popular PSR-20 implementation I found on packagist does just that: https://github.com/lcobucci/clock/blob/3.3.x/src/SystemClock.php#L30

So, if we used any spec-compliant PSR-20 implementation, we wouldn't be compliant with the OpenTelemetry spec (or, we'd multiple by 1_000_000 and be horribly inaccurate).

I'll bring this up at the next SIG, but my feeling is that we should not do this.

[bobstrecansky]

We have decided not to do this, as PSR-20 is currently not granular enough for our use cases (we need microsecond precision).