@gsquire - thank you! I will take a look and can definitely add the label. Much appreciated.

@gsquire - I believe we actually need the inverse trait impl here, as JavaScript is the source of time. chrono expects to use the underlying system, and so it would seem that we actually can only support From<worker::Date> for some chrono type.

Maybe I am looking at this the wrong way though.. I have a test endpoint that uses the following:

router
    .get("/now", |_, _| {
        let now = chrono::Utc::now();
        let js_date: Date = now.date().into();
        Response::ok(format!("{}", js_date.to_string()))
    })

Which fails with:

panicked at 'time not implemented on this platform', library/std/src/sys/wasm/../unsupported/time.rs:39:9

ah, it appears there is a feature in chrono that must be enabled:

# Cargo.toml

[dependencies]
chrono = { version = "0.4", default-features = false, features = ["wasmbind"]}

I will add this to the worker-sandbox, and look into conditionally enabling this feature in the worker crate along with chrono itself so it is not imposed on all users.

Thanks for reviewing. Is it still the case that we need the inverse implementation? Or is that feature enablement sufficient for your use case? I'm happy to follow up with another fix if need be.

No, I misinterpreted the error message. We should be good to go with this as long as you agree the "/now" endpoint example is sufficient (in the worker-sandbox directory in the root). Thanks!