no localtime on openbsd about time

[jhpratt]

Given that one of the issues you linked is for tracing, is your program multi-threaded at the time of invocation? If so, that is why the call is failing. If it crashes the program, please post a stack trace.

[brahin2]

not multithreaded. i posted over there but they said to bring the issue here.

[jhpratt]

Can you please provide some more information? At the moment, I have next to nothing to go off of.

[brahin2]

let me know what you need and will try. there really isnt much i can see to go off of either.
using the example from https://time-rs.github.io/book/#getting-started here is what i get:

~/time-demo % cat Cargo.toml
[package]
name = "time-demo"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
time = { version = "0.3", features = ["macros", "local-offset"] }

~/time-demo % cat src/main.rs
use time::OffsetDateTime;

fn main() {
    println!("Hello, world!");

    let now_utc = OffsetDateTime::now_utc();
    dbg!(&now_utc);

    let now_local = OffsetDateTime::now_local();
    dbg!(&now_local);
}

~/time-demo % cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.01s
     Running `target/debug/time-demo`
Hello, world!
[src/main.rs:7] &now_utc = 2023-10-18 0:57:52.375686939 +00:00:00
[src/main.rs:10] &now_local = Err(
    IndeterminateOffset,
)

[jhpratt]

After looking at the possible scenarios where this could return the error variant, the reason is that no one has implemented a way to check the number of running threads (for the current process) for OpsnBSD. This information is required for soundness.

[brahin2]

i wouldn't know where to find that to help out. hopefully someone can soon since this breaks a bunch of crates on openbsd. at the very least a note somewhere of what platforms arent supported and maybe why would help. like what would even be needed in libc for example if approrpiate.

[jhpratt]

Closing in favor of jhpratt/num_threads#21, which is where the issue would actually be resolved.