How to convert std::time::SystemTime to local time?

[SpriteOvO]

I am migrating from chrono crate to this crate because chrono has a security issue that hasn't been fixed yet.

In my code, I need to convert std::time::SystemTime to local time and then format it as a string. This is easy in chrono crate, it's just an into, but I don't find an equivalent in this crate. Is this still not possible or am I missing something?

use std::time::SystemTime;

mod use_chrono {
    use super::*;
    use chrono::prelude::*;

    pub fn system_time_to_local_time(system_time: &SystemTime) -> DateTime<Local> {
        (*system_time).into()
    }
}

mod use_time {
    use super::*;

    pub fn system_time_to_local_time(system_time: &SystemTime) -> ??? {
        ???
    }
}

fn main() {
    let now = SystemTime::now();

    let local_time = use_chrono::system_time_to_local_time(&now);
    println!("local_time (chrono): {}", local_time);

    let local_time = use_time::system_time_to_local_time(&now);
    println!("local_time (time): {}", local_time);
}

[jhpratt]

You should be able to do this (I haven't checked it):

let mut odt: OffsetDateTime = system_time.into();
let offset = UtcOffset::local_offset_at(odt)?;
odt = odt.to_offset(offset);

Keep in mind that the second line will fail if any of the following is true:

• the offset cannot be determined
• the program is multithreaded (this doesn't apply to Windows)
• the num_threads crate does not support the operating system, resulting in whether the program is multithreaded unknowable

I had never considered adding an OffsetDateTime::to_local_offset(self) -> Result<Self, error:IndeterminateOffset> method, but I could certainly see the utility. I will look into whether this makes sense and would be sufficiently used.

[SpriteOvO]

Thanks for your answer! Can you further explain the second limitation? Does this mean I can only call local_offset_at in the main thread, or should my program never spawn new threads? Why is there this limitation?

[jhpratt]

POSIX specifies that setting an environment variable is thread-unsafe, meaning that a lock must be held for the duration. Rust does this, though in a manner that is unsound. The same lock has to be used for everything, and Rust doesn't provide a way to use their lock. While getting an environment variable, by itself, is sound, it's the presence of a safe std::env::set_var in Rust that is why this restriction is in place.

Assuming you are not using Windows, the call will fail when there are multiple threads running. It doesn't matter which thread you call it from.

There has been a discussion ongoing for a few months now as to how this situation can be fixed. It's a very complex topic involving Rust, libc, and decades-old standards. Needless to say it's not an easy fix.

[SpriteOvO]

I see, thanks a lot! The code works, mark as answer.