Nope, don't have experience with it. When you say "you are expecting", are you implying that I'm expecting something I shouldn't?
I was hoping you would know what I'd need to do in this case to return the result that you think is right. At this point, I am not convinced I know enough about this subject to be sure.
After spending the last week reading about timezones and DST, I have come away thinking that its not as simple as it sounds, eg. deciding between prior or subsequent DST states at DST transition points, historical DST, dynamic DST, matching ISO timezone/DST rules, updating to the latest rules, CRT functions not supporting the latest changes (currently using Visual Studio 2008), Windows APIs not supporting these except in recent versions, libraries specifically written to handle timezone/DST not working correctly, leap seconds only applying prior to 1970 (although Windows 10 now includes them in API results), and so on.
Regarding /timeapi on|off: I thought this would be useful to allow comparisons between the CRT and API results. However, as the APIs are more up-to-date, the results may actually differ, not to mention that they may return different results on different versions of Windows.
That said, the new API implementation does have several bugs and I have implemented fixes in the next version, so we will have to see how that turns out.
