refactor: Use SystemTime for timestamps

[dima74]

Context

Fixes #4729

Solution

Use std::time::SystemTime for time stamps instead of std::time::Duration.

• Note that SystemTime requires std, so it will not be available inside WASM.
• Alternatively chrono::DateTime might be used, but it will be more complex (in particular we will have to handle leap seconds), so I am not sure that it is worth it

Migration Guide (optional)

Review notes (optional)

Checklist

• I've read CONTRIBUTING.md.
• (optional) I've written unit tests for the code changes.
• All review comments have been resolved.

[0x009922]

From SDK standpoint, it can be useful to clearly see the separation between durations and timestamps in the schema. Currently they are just *_ms: u64 fields.

[dima74]

From SDK standpoint, it can be useful to clearly see the separation between durations and timestamps in the schema. Currently they are just *_ms: u64 fields.

One option I see here is to create DurationMs and TimestampMs newtype wrappers for u64 and use them correspondingly

[mversic]

but how am I going to access it now in wasm?

[mversic]

it's needed

[dima74]

What do you think about adding separate methods specificaly for wasm?

#[cfg(not(feature = "std"))]
pub fn creation_time_ms(&self) -> u64 {

[0x009922]

As a proposal, we could use jiff::Timestamp/chrono::DateTime as a main type instead of std::time::SystemTime. Both can work in no-std context.

[s8sato]

I think core::time::Duration was a painstaking effort to make it compatible with no_std. Is it worth having separate methods to achieve semantic consistency? A time span from the origin can be considered a timestamp

[s8sato]

We need to decide something. Either introducing other no_std compatible types or staying in core::time::Duration is acceptable to me

[0x009922]

One option I see here is to create DurationMs and TimestampMs newtype wrappers for u64 and use them correspondingly

That would be helpful.