Bug with now_utc under windows

[Yuri6037]

Hi, I just recently tried a different approach of attempting to reconstruct local time (of course without using unsafe libc localtime_r) and I came across a strange bug with this crate as well as a winapi function that returns complete utter garbage:

• The function OffsetDateTime::now_utc returns 2023-08-09 5:23:49.2617291 +00:00:00 whereas it should have been about 20:23:49 instead (also notice that it is late of one day).
• The function GetTimeZoneInformation and the Bias field returns 8 minutes, what's this strange timezone UTC+00:08:00?

I thought the system was broken so I typed date on a PowerShell prompt and it does indeed output correct local time. Is this a known problem?

[jhpratt]

I'll take a look into this to the best of my ability, but I also don't possess a Windows machine. If there's a bug in winapi, it should be reported there. I have no choice but to assume that what it's providing is accurate.

And FYI, the unsoundness of obtaining the local offset doesn't exist on Windows.

[Yuri6037]

I'll take a look into this to the best of my ability, but I also don't possess a Windows machine. If there's a bug in winapi, it should be reported there. I have no choice but to assume that what it's providing is accurate.

And FYI, the unsoundness of obtaining the local offset doesn't exist on Windows.

I know the unsoundness is not on windows, but on unix I found a way to read exactly local system time not a possibly altered value by the TZ environment variable, for consistency I want the same effect on windows.

Btw, I found something even more alarming: the PowerShell command (Get-Date).ToUniversalTime() which gives UTC date time gives the same broken UTC time, so most likely my windows system is badly broken.

[jhpratt]

Initial view is there is no bug here. OffsetDateTime::now_utc ultimately uses SystemDateTime and adds the duration from the Unix epoch to OffsetDateTime::UNIX_EPOCH. This is an implementation that is relied upon in countless places and tested thoroughly. Given the incorrect information from winapi in another situation, I imagine something changed on Windows' side of things.

While looking into this, I noticed that winapi is unmaintained. windows-rs appears to be the replacement, and is maintained by Microsoft to boot. When I get the chance I will attempt to move from winapi to windows-rs, though I'll only be able to do this personally if the APIs aren't terribly different.

Btw, I found something even more alarming: the PowerShell command (Get-Date).ToUniversalTime() which gives UTC date time gives the same broken UTC time, so most likely my windows system is badly broken.

That's not good!

---

Given that I don't see any bug and that it's reproduceable completely outside of the crate, I'm going to close this. I will open a new issue to switch the underlying crate, though. Thank you in any situation!