Hi there 👋 After some internal discussion we would prefer if we can introduce the needed extensibility in a non-breaking way. We are in the process of designing the next mayor release, where we would revisit the topic and provide a more complete interface, but for now the quickest way to release the requested extensibility is to add a new cfg for the wasm32-unknown-unknown target.

My colleague @itsyaasir will support the effort 💪

Hi there 👋🏾 , expounding on what @eike-hass has said, currently the Timestamp::now_utc() has a cfg check for wasi and non-wasi compilation, we can have additional for wasm32-unknown-unknown target. This is a very minimal approach with limited moving parts. What do you think @frederikrothenberger ?

Hi @frederikrothenberger , Is it possible to import and call an external function from a WebAssembly module in an Internet Computer (IC) canister?

One of the approaches suggested by the team involves implementing a now_utc function by importing an external function from a Wasm module. While this approach would involve using the unsafe keyword in Rust, it is considered acceptable within this context. Here is a rough outline of the implementation:

#[link(wasm_import_module = "time")]
extern "C" {
    fn now() -> u64;
}

fn utc_now() {
	unsafe { now() }
}

This method allows us to use the external function to get the current time. Would this approach be feasible ?

@itsyaasir: We actually do something similar in our SDK:

#[link(wasm_import_module = "ic0")]
extern "C" {
    pub fn time() -> i64;
}

But I can't assume the existence of that module for generic wasm32-unknown-unknown. Or is the idea to add a feature flag for ICP specifically?

Hey @frederikrothenberger, to keep this project as general purpose as possible we won't depend on ICP's SDK nor we will add a feature flag specifically for ICP.

We think the approach we showcased in our previous messages should hopefully solve your issue as well as allowing other users to work with their own concept of time.

Basically, the approach consists on allowing the user to provide their definition of time through a foreign function fn now() -> i64 defined in a WASM module time.

Here is the code that deals with what I just discussed:

#[cfg(all(target_arch = "wasm32", not(target_os = "wasi")))]
pub mod wasm_time {
  #[link(wasm_import_module = "time")]
  extern "C" {
    /// Returns the timestamp
    pub fn now() -> i64;
  }
}

#[cfg(all(target_arch = "wasm32", not(target_os = "wasi")))]
#[no_mangle]
pub fn now_utc() -> Self {
  let ts = { unsafe { wasm_time::now() } };
  Self::from_unix(ts).expect("Timestamp failed to convert system datetime")
}

From your previous message it seems this approach could easily be applied to your specific use case: if you create a time::now WASM function that simply forward its implementation to your ic0::time function everything should work as intended - given the right modules are linked out.

By default we still want to depend on js_sys to get the current time in WASM targets, thus we will lock the aforementioned code behind an extern-time feature (which shall be disabled by default).

Could this work for you?

@itsyaasir: Sorry, this task got pushed back on my side due to other priorities. And I'll be on PTO for the next two weeks. I'll report back after.

Hi @itsyaasir

From your previous message it seems this approach could easily be applied to your specific use case: if you create a time::now WASM function that simply forward its implementation to your ic0::time function everything should work as intended - given the right modules are linked out.

Can this forwarding function be implemented in a library that has a dependency on identity.rs? We don't want our devs needing to go through additional / custom linking steps. They should simply be able to pull in the library, compile to wasm and deploy (as with any other functionality they pull in).

@itsyaasir: So after thinking more about this, I don't think importing a function from some generically named wasm module is convenient for users of that feature, as it would impose additional steps in the build process.

However, what we could do is take a similar approach to the custom feature of getrandom. See here for the details: https://docs.rs/getrandom/latest/getrandom/macro.register_custom_getrandom.html

What do you think? This would allow the registration of a custom time function regardless of the platform without going through additional build steps and we could also gate the macro behind a feature flag.

@frederikrothenberger

After liaising with the team, I think this sounds like a great approach. You are welcome to contribute to this by opening a pull request (PR), and you can invite me and the team to review it. Please let me know if you have any more questions or concerns.

Thank you.

@itsyaasir: I opened #1397.