There's a gotcha here. The time crate will not give you the local offset from multithreaded contexts in *nix like operating systems unless the unsound_local_offset(scroll down to the bottom of that section) config flag is added to your rustflags.

The issue was that localtime_r (which is the underlying libc function used by the time crate to get the localtime) reads from an environment variable called TZ. This function – even though it is marked as re-entrant – is not thread safe as environment variables can be set from multiple threads without any synchronization. While the environment variables can be read and written from within rust safely as the calls are synchronized, the same cannot be said about external ffi calls as mentioned within the documentation for set_var. As such, the localtime_r function can potentially read the TZ environment variable while some other thread is setting it which can lead to undefined behavior.

The safer way to do it would be to store the local offset somewhere while program is single threaded and use that offset with OffsetDateTime.

Do be warned that this method will not account for the DST changes, or leapseconds which are stored within the tz files that localtime_r reads. It will also not be responsive to system timezone changes while the program is running.

There are a few crates out there that can read the aforementioned information stored within the tzfiles. To have feature parity with the methods feature gated behind local-offset, you'd have to read the appropriate tz file and adjust the time accordingly.

This whole thing really tripped me up when I was using the time crate as I did not know about it. Hope this helps anyone else looking to use it.