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@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