Correct timezone info and name is important for some games which, e. g., expect the user region guessed from timezone information match user region. 1. Some few time zones, e. g., Europe/Dublin, are defined with "inverse DST" on Unix. Dublin standard time is IST (Ireland Standard Time, not to confuse, e. g, with Indian Standard Time) which is in effect on summer, while daylight shift is defined as 1 hour back in autumn. libc time functions return tm.tm_isdst as 0 now (in winter) and 1 in summer. That breaks various things: - GetLocalTime() is plainly wrong, the current timezone offset calculation doesn't mind such case. That is fixed by "ntdll: Get current timezone bias from user shared data.", "server: Avoid relying on tm->tm_isdst in set_user_shared_data_time().". - Timezone matching in get_timezone_info() goes wrong in various ways for such a case. For a start, it ends up with wrong timezone bias and a year of only 1 hour length now. "ntdll: Fix get_timezone_info() for timezones defined with inverse DST on Unix." fixes all of that and lets the algorithm correctly find GMT timezone for Dublin (instead of 'W. Central Africa Standard Time' as it does now); 2. There are cases when all the current zones have all the current year parameters matching, so the current algorithm picks the first one. That result in the timezone name and details being from absolutely different region sometimes. Similar issues were partially addressed in the past disambiguating by past date conversion (e. g., https://bugs.winehq.org/show_bug.cgi?id=50213 , commit 22612bcff5ecc7ece4acc4325aa8b19e6129b2cf ). But that covers only some part of the cases, also not quite correctly (the existing disambiguation breaks zone matching for a few existing zones). E. g, right now Mexico City (set as America/Mexico_City Unix localtime) matches to Canada Central Time Zone (can in theory be disambiguated using histroy info), but there are also cases when there are different zones with fully identical parameters without DST which can't be disambiguated this way ar all. So it seems to me that for correct results it is both unavoidable and much simpler to have an explicit mapping f rom Unix timezone and Windows timezone. So, even for the cases where it is possible, we don't have to do some very ad-hoc and unobvious disambiguation checks and have the match just generated from the Unicode data we are already parsing in make_unicode. I made that in "ntdll: Try to determine system time zone to Windows zone by name.". At this point I made a thorough test of whether the matching is now correct across all the timezones and the changes don't break anything. I am attaching test C program which prints current locale info, bash script which runs this for every Unix timezone as 'TZ=<tzname> wine a.exe' and greps output for expected Windows timezone (the input to bash script with all the zone names is also attached). [test_tz2.sh](/uploads/150ac3566177e84db0f575457ef0a08c/test_tz2.sh) [tzt.c](/uploads/5368b882a04ee9181733a9e03f5f10ad/tzt.c) [test.txt](/uploads/57ab6f8e37609d9adf0cac16521c4574/test.txt) I also ran this for time(NULL) in the beginning at get_timezone_info() offset 3 month, 6 month, and 9month to make sure that the code is still correct through the timezones when the current time's DST state changes. That revealed some additional issues: - Match was failing for Asia/Dili, Asia/Jayapura, Etc/GMT-9, Pacific/Palau, due to check_tz_name() check which is not quite correct. I dropped that check in "ntdll: Drop additional TZ matching with match_tz_name().", because now the part which matches Unix timezone name is supposed to disambiguate the timezones anyway; - Africa/Casablanca is special, at least this year. It changed to STD on Feb15 for some reason and going to DLR month later, on Mar22. The present find_dst_change() binary search algorithm doesn't work well for Casablanca this year, it skips the dates (it is in general mentioned in https://bugs.winehq.org/show_bug.cgi?id=50532 but at the present moment Casablanca looks like the only case which hits this issue). I made the search a bit more reliable in "ntdll: Better search for DST change in find_dst_change()."; - Australia/Lord_Howe : performs shift to STD time at 2:30, which is reflected in Unix timezone, while Windows timezone info has 2:00 (both on up to date Windows 11 and in our data). I relaxed the match in "ntdll: Accept 30min shift in match_tz_date()." because I suspect that Windows just never puts half hours there but it is hard to be sure because that looks like the only case at the current moment. Finally, there are 3 remaining failures in my test (while the failure happens when the actual timezone name didn't match our mapping); - America/Scoresbysund: seems to be an error in Unicode winsowsZones.xml: matches that to "Azores Standard Time" but that is actually "Greenland Standard Time" (Azores Standard Time is plainly differs in current time), but fallback algorithm finds the correct zone, so this is not an actual issue currently; - Antarctica/Casey: similarly (but with wrong matching result), should be "W. Australia Standard Time", but is listed as "Central Pacific Standard Time". The algorithm finds "China Standard Time" which is wrong (both before and after my changes), but it looks like it is impossible to distinguish other than by name: there is no DST in neither zone, nor static nor dynamic; - Antarctica/Vostok: similar, mapped in Unicode data to "Central Asia Standard Time" which is incompatible zone. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10134#note_129931