[PATCH] msvcrt: Use RtlQueryTimeZoneInformation when MUI not required.

[Piotr Caban]

On 12/21/18 4:50 AM, Zebediah Figura wrote:
> On 12/20/2018 04:46 PM, Alistair Leslie-Hughes wrote:
>> TIME_ZoneID copied from dlls/kernel32/time.c
>>
>> Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=46266
>> Signed-off-by: Alistair Leslie-Hughes <leslie_alistair at hotmail.com>
>> ---
>>
>> If we dont care about an invalid TIME_ZONE then we have the possiblity
>> to use GetDaylightFlag to reduce the amount of code.
>> MSVCRT__ftime64
>> ....
>> buf->timezone = tzinfo.Bias +
>>        ( tzid == TIME_ZONE_ID_STANDARD ? tzinfo.StandardBias :
>>        ( tzid == TIME_ZONE_ID_DAYLIGHT ? tzinfo.DaylightBias : 0 ));
>>
>>   dlls/msvcrt/time.c | 144 
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++-
>>   1 file changed, 143 insertions(+), 1 deletion(-)
>>
> 
> MSDN says that the timezone field is filled in from _timezone, and 
> presumably also dstflag is filled in from _daylight. This could probably 
> be tested, and, if true, seems much cleaner.
I've done some tests and it looks like we should use _timezone in 
_ftime64 implementation. Changing the timezone setting after msvcrt time 
structures are initialized is not changing timezone field returned by 
_ftime64. Also the structures are initialized on _ftime64 call.

I've also done some tests to check what happens when daylight saving 
time change occurs while a program runs. In this case the _daylight 
value is not updated but dstflag is. It means that we can't use 
_daylight for dstflag value.

I've also done some quick performance tests of GetTimeZoneInformation 
function and it works fast on Windows (it takes over 10 seconds to 
execute the function 10k times on wine while it takes ~10ms on Windows).

I'll send a patch that fixes _ftime64.

Thanks,
Piotr