Use raw u64 instead of chrono on RTC API

[robertbastian]

Thank you for your contribution!

We appreciate the time and effort you've put into this pull request.
To help us review it efficiently, please ensure you've gone through the following checklist:

Submission Checklist 📝

• I have updated existing examples or added new ones (if applicable).
• I have used cargo xtask fmt-packages command to ensure that all changed code is formatted correctly.
• My changes were added to the CHANGELOG.md in the proper section.
• I have added necessary changes to user code to the Migration Guide.
• My changes are in accordance to the esp-rs API guidelines

Extra:

• I have read the CONTRIBUTING.md guide and followed its instructions.

Pull Request Details 📖

Description

#3185

Testing

[bugadani]

Why isn't our own time::Instant good here?

[robertbastian]

I assume because that's not using the UNIX epoch.

[bugadani]

Neither does the hardware. We can redefine Instant to have an undefined epoch, we can state that now() returns time since boot, and RTC has a user settable 0 by set_current_time, it'd all be mostly just documentation change.

[robertbastian]

Well I don't know what to tell you, I advocated for dumb types in #3185, but @MabezDev wanted this to be a proper datetime type.

esp_hal::time::Instant uses boot time, we should not start creating them with UNIX time here. It should not be possible to use a UNIX timestamp where a boot timestamp is expected, and vice versa.

jiff::Timestamp is an improvement over chrono::NaiveDateTime.

[MabezDev]

Well I don't know what to tell you, I advocated for dumb types in #3185, but @MabezDev wanted this to be a proper datetime type.

I think the suggestion here to add jiff as a dev dep and create a doc example is a nice compromise. I'd be happy to have a dumb type API provided it has a example that shows how to use it with some time library. Please note that the timer we use can't do nanosecond precision, only microsecond.

I think the following comment is also correct, it should return a u64.

[MabezDev]

LGTM, thanks!

Just need to sort CI out now, don't worry about the MSRV check, we need to resolve that seperately.

[bjoernQ]

LGTM

[robertbastian]

Is there a way to actually obtain an Rtc in an docs test? The existing examples are no_run.

[robertbastian]

Jiff is annoying to use here because no-alloc time zone support is limited. I could remove the example using the time zone, or rewrite it using chrono.

[MabezDev]

Jiff is annoying to use here because no-alloc time zone support is limited. I could remove the example using the time zone, or rewrite it using chrono.

I'd prefer without alloc, if we can get away with it. Is it possible to bundle some time zones statically at compile time?

[BurntSushi]

It will be in the next Jiff release. Maybe this week. The functionality (via a proc macro) is on master, but I have some polishing to do before it's released.

[robertbastian]

I have removed the examples because I cannot get them to work. Feel free to add them yourselves if you have a faster test cycle than waiting for CI, or know how exactly to set them up.

[bugadani]

I have removed the examples because I cannot get them to work

You should be able to run cargo xtask run-doc-tests esp-hal esp32c3 locally