Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
time: TestLocalZoneAbbr fails on Windows in "W. Europe Standard Time" #12015
What version of Go are you using (go version)?
N/A, commit bc5a6ce.
What operating system and processor architecture are you using?
Windows 7, 64-bit.
What did you do?
Ran src/all.bat as administrator and with the firewall temporarily turned off
What did you expect to see?
All tests passing
What did you see instead?
After uninstalling Nod32 and disabling the firewall all tests but one now passes:
Here you go:
@dajoo75 thank you.
Your syscall.GetTimeZoneInformation seems to return "Västeuropa, normaltid" and "Västeuropa, sommartid" for your time-zone descriptions. Go struggle to convert these into time-zone. What it does, it looks for appropriate registry key under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones. Perhaps you can follow code in zoneinfo_windows.go to see where it fails. Just insert some print statements here and there. Something like that:
Then just run
command to see what is going on.
I've done some digging and as far as I can see the function toEnglishName (zoneinfo_windows.go) doesn't take into account MUI or Multilingual User Interface information in the registry (MUI_Std and MUI_Dlt points to localized resource strings for timezones stored in tzres.dll) and that is why it is failing to find a match for "Västeuropa, normaltid" and "Västeuropa, sommartid" (Swedish).
Some information I found while researching this:
Here's an example program I put together (RegLoadMUIString is not in the example) that can extract the localized resource strings (at least on my computer ;-)):
Example output on my computer:
And here are also the traces you requested:
Nice explanation, thank you very much. I use English version of Windows. So I don't get to play with all these things. My loss.
I think we should use RegLoadMUIString to here. I tried using RegLoadMUIString on my windows 7 pc, but it fails with ERROR_INVALID_DATA. I will play some more.
If RegLoadMUIString does not work for me, perhaps we can do something similar to your code. We should also call ExpandString in case there are some environment variables to expand.
Feel free to send change if you like. But no pressure, I will do it myself, if no one else wants to do it.
GetMUIStringValue tries as a convenience to resolve string values even for pathless resource DLLs by searching the system directory (one of several paths used by the system's standard DLL search order algorithm). This would not be needed if regLoadMUIString searched for pathless DLLs itself, but it doesn't, instead it needs an absolute path, otherwise it will fail. This approach works fine for solving issue #12015 (handle localized time zone names; for which GetMUIStringValue was created) since tzres.dll that is used to resolve localized time zone names has no path in the registry but is located under the system directory. However, this approach will fail if a pathless DLL is located somewhere else than the system directory. Because of this limitation GetMUIStringValue may have to be revised in the future to allow for custom paths, possibly through another version of the function. See also: https://msdn.microsoft.com/en-us/library/windows/desktop/ms724890%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx Change-Id: Ida66a0ef1928e0461ce248c795827902d785e6cd Reviewed-on: https://go-review.googlesource.com/13929 Reviewed-by: Rob Pike <firstname.lastname@example.org>