no field `tm_gmtoff` on type `tm`

[chungwong]

I am having a similar issue with #495 but with a different cause.
I am compiling on Debian 10 for ESP32(target riscv32imc-esp-espidf)

The difference is I am using time v0.3.13 already and the error

error[E0609]: no field `tm_gmtoff` on type `tm`
  --> /home/chung/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/time-0.3.13/src/sys/local_offset_at/unix.rs:49:27
   |
49 |     let seconds: i32 = tm.tm_gmtoff.try_into().ok()?;
   |                           ^^^^^^^^^ unknown field
   |
   = note: available fields are: `tm_sec`, `tm_min`, `tm_hour`, `tm_mday`, `tm_mon` ... and 4 others

is caused by this line https://github.com/time-rs/time/blob/v0.3.13/src/sys/local_offset_at/unix.rs#L49

The deps in Cargo.toml is as below

[profile.release]
opt-level = "s"

[profile.dev]
debug = true # Symbols are nice and they don't increase the size on Flash
opt-level = "z"

[features]
pio = ["esp-idf-sys/pio"]

[dependencies]
anyhow = "*"
embedded-svc = "*"
esp-idf-svc = "*"
esp-idf-sys = { version = "0.31.6", features = ["binstart"] }
log = "*"
time = { version = "0.3.0", features = ["local-offset", "formatting"] }


[build-dependencies]
anyhow = "1"
embuild = "0.29"

Is there a hidden requirment on libc?

[jhpratt]

Is there a hidden requirment on libc?

Yes. That's how the local offset is obtained.

I am compiling on Debian 10 for ESP32(target riscv32imc-esp-espidf)

I just checked, and I'm honestly surprised that that target even has support for std. time, by default, assumes the existence of the tm_gmtoff field in libc. It is possible (on my end) to opt out of this. I'll take a look to see if adding riscv32imc-esp-espidf would result in a successful compilation.

[jhpratt]

Actually, this is a tier 3 target, meaning official builds are not available. Would you mind providing instructions on how to set up my local environment to support this target? I run Fedora 36 if it matters.

[chungwong]

Sure, this easiest way I coul think of

git clone https://github.com/ferrous-systems/espressif-trainings

cd espressif-trainings/intro/hardware-check/

cat rust-toolchain.toml # beware of the toolchain, 
I use 
[toolchain]
channel = "nightly"

add time = { version = "0.3.0", features = ["local-offset", "formatting"] } to Cargo.toml

cargo build --release

Some of the prerequisites I could have missed and here is the reference https://espressif-trainings.ferrous-systems.com/02_2_software.html

[jhpratt]

Thanks! I was able to reproduce the error locally. I just cross-checked libc, as that's ultimately what determines what I'm able to do. I'm going to use this list of targets as an allow list, rather than a deny list. That way every target will get something (even if it's just returning None) rather than a compile error.

In the future, #[cfg(accessible)] will wholly eliminate this issue for all targets, as I could use #[cfg(accessible(libc::tm::tm_gmtoff))] (and its negation) where appropriate.

[jhpratt]

Just pushed up that change. I wasn't able to get that repository to run cargo check fully, but it compiled time without issue.

[chungwong]

Thanks for the fix and it compiles now.
Could I please confirm the behaviour on tm_gmtoff?

tm_gmtoff is not available on build target riscv32imc-esp-espidf (my guess so far) and thus calling anything related will return time::error::IndeterminateOffset.

dbg!(time::OffsetDateTime::now_local());

time::OffsetDateTime::now_local() = Err(
    IndeterminateOffset,
)

[jhpratt]

Correct. There is a workaround that may work on that target, but it relies on using RUSTFLAGS="--cfg unsound_local_offset".

[chungwong]

Where is datetime initialised?

The unsound_local_offset flag looks like depends on something.

error[E0425]: cannot find value `datetime` in this scope
   --> /home/chung/.cargo/git/checkouts/time-91f7c71100c3ea58/6894ec1/src/sys/local_offset_at/unix.rs:141:45
    |
141 |     let diff_secs: i32 = (local_timestamp - datetime.unix_timestamp())
    |                                             ^^^^^^^^ not found in this scope

[jhpratt]

Apparently it's not. Keep in mind that using that flag is both unsound and not supported, though. There are no guarantees whatsoever — including a successful compilation. I'll take a look at this specific case, but it's not something ordinarily checked by myself or CI.

[MikiLoz92]

Just leaving this comment here for other fellow ESP32 users, to note that since version 0.3.18, this cfg flag was changed to a combination of two things:

1. Enabling the local-offset feature within the time crate.
2. Calling the following function: unsafe { ::time::util::local_offset::set_soundness(Soundness::Unsound); }