Program panic because of year 2038 issue for embedded 32bits system

[muzili]

Run following program in embedded 32 bits system(hisi 3516dv300)

fn main() {
    let now = chrono::Utc::now();
    println!("Hello, world!");
}

the program panics with following errors.

date -s '@2147483647'
RUST_BACKTRACE=1 ./chrono-y2038
thread 'main' panicked at 'system time before Unix epoch: SystemTimeError(2147483154.007637941s)', /home/zgli/.cargo/registry/src/github.com-1ecc6299db9ec823/chrono-0.4.19/src/offset/utc.rs:49:58
stack backtrace:
   0: rust_begin_unwind
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:483
   1: core::panicking::panic_fmt
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/panicking.rs:85
   2: core::option::expect_none_failed
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/option.rs:1234
   3: core::result::Result<T,E>::expect
             at /home/zgli/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/result.rs:933
   4: chrono::offset::utc::Utc::now
             at /home/zgli/.cargo/registry/src/github.com-1ecc6299db9ec823/chrono-0.4.19/src/offset/utc.rs:49
   5: chrono_y2038::main
             at /home/zgli/code/rust/chrono-y2038/src/main.rs:3
   6: core::ops::function::FnOnce::call_once
             at /home/zgli/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[mike-kfed]

what would your expected behaviour be? for chrono::Utc::now() to return a Result<T, E> I assume, and then you can handle the SystemTimeError yourself? I'd be interested to fix this issue, but I am afraid this will not work with keeping backwards compatibility (e.g. return signatures of every function running into 32bit limits will need to change, given my proposed change is the desired one).

[pitdicker]

The problem is in the standard library, which defined SystemTime as a thin wrapper around time_t.

I am pretty sure this issue was fixed by rust-lang/rust#96657. In it the standard library switched to using __clock_gettime64 on 32-bit linux-gnu.