-
Notifications
You must be signed in to change notification settings - Fork 497
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
request for guidance: accessing GetTimeZone in iana-time-zone
crate
#2317
Comments
I think you may be confusing https://kennykerr.ca/rust-getting-started/windows-or-windows-sys.html Basically, the The So you would certainly avoid a ton of unsafe code by using the |
Practically speaking, how would you suggest calling Windows.Globalization with Rust 1.48 (our MSRV)? Something like proposed in strawlab/iana-time-zone#96 ? Our minimum supported rust version of 1.48 comes from tracking this with |
I glanced at the code and it seems all you really need is a How about simply calling out to the platform provided ICU (via Something like... [dependencies.windows-sys]
version = "0.42.0"
features = [
"Win32_Globalization"
] use windows_sys::Win32::Globalization::{ucal_getDefaultTimeZone, U_ZERO_ERROR};
fn main() {
let mut status = U_ZERO_ERROR;
let buffer_size = unsafe { ucal_getDefaultTimeZone(std::ptr::null_mut(), 0, &mut status) };
let mut buffer: Vec<u16> = Vec::new();
buffer.resize((buffer_size + 1) as _, 0);
status = U_ZERO_ERROR;
unsafe {
ucal_getDefaultTimeZone(buffer.as_mut_ptr(), buffer.capacity() as _, &mut status);
}
println!("{}", String::from_utf16_lossy(&buffer));
}
|
@riverar, thank you! That looks exactly like the right function to use. The only problem is that is the function was only introduced in Windows 10 v1709, which is newer than the Windows 10 v1607, which is not EOL for the next 3 years and 8 month. I know too little about Windows' update policy to know if such functions get backported. Windows 8.1's EOL was earlier this month, so at least this one won't be a problem. What do you think? Can we already ship a library that uses this "new" function, or is it still too early for that? |
Hmm Windows 10, version 1607 for Education, Enterprise, and IoT Enterprise reached EOL April 9, 2019
Not sure if that third-party site is correct? |
The Windows Knowledge Base seems to support that date: When does Microsoft Support end for Windows 10 Enterprise 2016 LTSB 1607?:
But I'm not an "enterprise user", so maybe I am misinterpreting something. |
Ah Windows 10 LTSB 1607 is on the fixed lifecycle. https://learn.microsoft.com/en-us/lifecycle/products/windows-10-2016-ltsb Let me take a peek at that build. |
Yeah to support LTSB 1607, you'll need to either consume the timezone mapping file on disk or call into the WinRT implementation. So perhaps it's best to simply abandon strawlab/iana-time-zone#96 and leave it as-is? Looks solid; what's the downside? |
The motivating factor for the PR was to drop a no-longer current dependency. (The current implementation in git main depends on If we're going to accept no-longer current dependencies: why not then depend on the oldest |
Can you link to information about the timezone mapping file? That option sounds potentially appealing. After a couple minutes of searching, I still haven't found anything that looks relevant. (But again, I am far from expert with Windows.) |
What breaks when you move to |
The file lives at |
The PR for updating to |
Ah thanks for your patience, I understand now. So basically:
Thinking 💭 |
I had a quick look and many of the use windows::{core::Result, Globalization::Calendar};
fn main() -> Result<()> {
println!("{}", Calendar::new()?.GetTimeZone()?);
Ok(())
} Let me know if that will let you adopt the
Note that |
Sure, if we could use We switched to |
#2318 now provides support for using (most) of the |
Thank you all! |
Hi, I am a developer of the
iana-time-zone
crate. I would like to ask for advice/help from the experts about how to best support Windows moving forward. At the high level, our goal seems very simple. We want to call the Windows.Globalization Calendar.GetTimeZone function from Rust. As our crate currently gets over 100k downloads most days and we are contemplating a substantial rewrite of our Windows specific code - with lots ofunsafe
- I would like to ask for help here.Narrowly, the subject at hand is strawlab/iana-time-zone#96, a PR which drops
windows-sys
in favor ofwindows-targets
and contains plenty ofunsafe
. As I am no expert in the relevant Windows APIs, I have a difficult time deeply evaluating this PR. So, at the shallowest level, it would be great if we could get some eyes on that PR for better review. It seems that #2165 removed the APIs we were using fromwindows-sys
0.45.More broadly, I would ask if there is a chance that the relevant APIs will get added back to
windows-sys
? If not, should we consider that the correct thing to do is indeed to usewindows-targets
?The following is perhaps a question for a different venue, but also relevant in my mind to the issues at hand: why are crates such as tokio and chrono NOT depending on the high-level
windows
crate but instead on the low-levelwindows-sys
crate? A long time ago,iana-time-zone
depended on thewindows
crate (version 0.7) and our implementation was simple and used nounsafe
. It seems to me like we are going backwards by introducing so much low-levelunsafe
-using code. As we are a dependency now of the very popularchrono
, I do not want to introduce a dependency which they themselves do not have.My overall fear is that we are going backwards here - keeping or adding substantial complexity (which we also have to maintain). Would it be possible to drop all this low-level stuff and let the experts (i.e. the developers of
windows-rs
here) handle the relevant details? That would be my goal.Thanks for your work on
windows-rs
and thanks in advance for help here!The text was updated successfully, but these errors were encountered: