Open jhpratt opened 3 years ago
@jhpratt thanks for bringing this up and sorry for taking a few days to get back to you!
I was actually aware of the fact that the chrono crate simply ignores the unsoundness rather than addressing it. Reading back the commit message, I see that it gives a different impression and seems perhaps a bit uncharitable of the time crate. That was not my intention, so I apologies for it.
I would love to go back to the much leaner time crate, but I was not able to find a way to get it to address my use case, which is: obtain the current date in YYYY-MM-DD format when running on Linux. To be completely honest, I didn't spend too much effort looking for a way to do that, especially after I realized that the chrono crate would paper over the issue for me.
Can you recommend a way to do the above using the time crate? If so, I'll gladly switch back - and make sure the corresponding commit message does a better job at explaining the situation this time ;)
Thanks again!
Not an issue! I didn't take offense, just wanted to make sure that you were fully informed.
I didn't take the time to look through the repository. If it's a library, you can't enable the functionality (this is by design). If it's a binary, you can set RUSTFLAGS="--cfg unsound_local_offset"
, which will enable the internal cfg (and thus the unsoundness). If you never call setenv
, you've got nothing to worry about with regard to soundness.
The time crate has unsoundness, but so does chrono (for the exact same reason). Chrono just ignores this fact, while the time crate confronts it and forces end users to explicitly opt in to the unsoundness. Commit 4ca4987 is based on the false premise that "The chrono crate doesn't suffer from this limitation".
I have no problem with you switching crates, but I want to make sure that you're aware that your reasoning has flaws.