Switch from the chrono clock feature to now

[edmorley]

In #1192, chrono was added as a dependency of the opentelemetry-stdout crate in order to support outputting timestamps in human readable format.

In that PR, all Chrono features were disabled apart from the clock feature.

However, since that change landed, chrono v0.4.32 has added support for an even finer-grained feature named now, which is a subset of the clock feature - that excludes timezone support, and so avoids pulling in many timezone related crates.

opentelemetry-stdout only uses chrono's UTC features, so we can safely switch from using the clock feature to using now instead.

After this change, the following transitive dependencies are no longer pulled in:

• android-tzdata
• android_system_properties
• cc
• core-foundation-sys
• iana-time-zone
• iana-time-zone-haiku
• windows-core
• windows-targets
• windows_aarch64_gnullvm
• windows_aarch64_msvc
• windows_i686_gnu
• windows_i686_msvc
• windows_x86_64_gnu
• windows_x86_64_gnullvm
• windows_x86_64_msvc

See:
chronotope/chrono#1343
https://github.com/chronotope/chrono/blob/main/README.md#crate-features

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: edmorley / name: Ed Morley (0320780)

[shaun-cox]

Thanks for the contribution!

[cijothomas]

Thanks a lot! ❤️

[edmorley]

The coverage CI job is failing for unrelated errors in another crate - any ideas?

 ---- exporter::config::collector::tests::test_set_collector_endpoint stdout ----
thread 'exporter::config::collector::tests::test_set_collector_endpoint' panicked at opentelemetry-jaeger/src/exporter/config/collector/mod.rs:575:9:
assertion `left == right` failed
  left: "ConfigError { pipeline_name: \"collector\", config_name: \"collector_endpoint\", reason: \"invalid uri from environment variable, invalid uri character\" }"
 right: "ConfigError { pipeline_name: \"collector\", config_name: \"collector_endpoint\", reason: \"invalid uri from the builder, invalid format\" }"

[hdost]

We have a bug open for it, it's a flaky test, don't worry.

[cijothomas]

@hdost We should not merge PRs while release is pending. We need to resolve conflicts again in #1539

[hdost]

@hdost We should not merge PRs while release is pending. We need to resolve conflicts again in #1539

There were no conflicts from this merge. We were still waiting on the no defaults PR #1562 at the time, so even if there were conflicts it would have been 1 small line diff and as this is a leaf had no downstream affects on other crates.

In general, I agree we need to establish some sort of process, but there was only a net good considering how often we get asks for releases.

[cijothomas]

@hdost We should not merge PRs while release is pending. We need to resolve conflicts again in #1539

There were no conflicts from this merge. We were still waiting on the no defaults PR #1562 at the time, so even if there were conflicts it would have been 1 small line diff and as this is a leaf had no downstream affects on other crates.

In general, I agree we need to establish some sort of process, but there was only a net good considering how often we get asks for releases.

Yes. I only meant to re-highlight the need to establish a process. Fully agree with your reasoning for merging this.