Being in the zone may not be the best way to get the time right

by Michael S. Kaplan, published on 2010/02/04 07:11 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/02/04/9958063.aspx

So the other day a developer at Microsoft who was doing a ton of grabbing of UTC SYSTEMTIME values and logging them in the local time of the user¹ noticed some significant performance regressions between Windows Server 2003 and Windows Server 2008 R2.

After doing some work to isolate where the extra time was being spent, he found that s ton of the time was spent around the following key:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Time Zones\Pacific Standard Time\Dynamic

Luckily, the original "Father Time" Geoff Pease² was around to describe what was going on here in some detail....

You are hitting this because of Dynamic Time Zone support that was added.
 
Everything you need is NOT in a TIME_ZONE_INFORMATION structure. The structure only has room for the “current” time zone and not historical ones.
 
In 2007, the US changed the start and end dates for Daylight Savings time. Any date BEFORE the transition needs to use a different set of rules than those AFTER the transition.
 
Because of historical applications that have no clue about this change and to keep them displaying the historically accurate time stamps (meaning then do not change whichever side of the transition you are on), the system hast to play some games.
 
To get around this, the system has to play some games in matching a “current time zone” to lookup as needed historical time zone data about the year. 
 
If you want the entire server to disable historical lookups, turn off Daylight Savings Time (which you’ve already tried and hated) OR do what you did – call GetTimeZoneInformation() to get the TZI and pass it in… but then add zero’ing out the Standard and Daylight names. This will cause a time zone comparison to fail where the legacy API is trying to determine if the “current time zone” is the same time zone you just past it (and if true, the do the historical lookups which hits the registry where these tables are stored). By failing this comparison, the historical comparison’s do not kick in and the registry accesses go away.
 
This technique comes with a down side – since you are in essence “making your own TZI,” you’ll need to refresh the TZI structure once a year or once a day or whatever you like (less often, the better but not enough to make you uncomfortable J). You also need to make sure that the timestamps you are passing in are match the TZI that you pass in. Converting times from different years using this technique will generate “bad times” during the area where DST change from year to year. If you are using this for “current time logging,” this should work pretty well for you.

Now as it turns out, the developer stumbled across another workaround as well (one that also avoids the dynamic support that was added) -- basically changing code depending on SystemTimeToTzSpecificLocalTime like this:

FILETIME ftUtc;
::GetSystemTimeAsFileTime( &ftUtc );
//
// code to perform elapsed time calcs would go here...
//
SYSTEMTIME stUtc, stLocal;
::FileTimeToSystemTime( &ftUtc, &stUtc );
::SystemTimeToTzSpecificLocalTime( NULL, &stUtc, &stLocal );
// log away using the nicely structured stLocal...

and instead do code more like this:

FILETIME ftUtc, ftLocal;
::GetSystemTimeAsFileTime( &ftUtc );
//
// code to perform elapsed time calcs would go here...
//
::FileTimeToLocalFileTime( &ftUtc, &ftLocal );
SYSTEMTIME stLocal;
::FileTimeToSystemTime( &ftlocal, &stLocal );
// log away using the nicely structured stLocal...

Since FileTimeToLocalFileTime never does any of the dynamic time zone lookup work (it just uses the current time) you will get performance behavior analogous to the Server 2003 code before dynamic time zones existed.

Now both still do the static lookup and whether the extra several conversions is faster or slower than the one missed registry key hit for the non-existent time zone is probably too small to be measured in most cases....

The scenario and the solution raise two problems for me:

1. The dynamic time zone stuff was added for a reason, so there is potentially a chance to be off by an hour if one is dealing with historical dates rather than the current time³.
2. Taking the time to convert and log the times causes all of the logs to be in the local time, which makes both looking at the logs by people in other time zones and comparing values across the possible range of values of successive years harder to do with complete accuracy since the original source is now lost without going back with dynamic time zone information later; leaving all times in UTC and only converting for display purposes in an event log if and when it is ever needed⁴ is really always going to be faster.

Similar to that time that Opera was calling SetLocaleInfo tons of times before they fixed the problem (discussed here), any time one is doing something repeatedly, asking honest questions about how much work one has to with each iteration is not an unreasonable approach to optimization....

1 - Actually, what he was doing/why he was doing it was a bit more complicated than this but the details are not entirely relevant to this blog; the description above is close enough!

2 - Title explained previously in You want to change the time zone? Eto Akta Gamat!

3 - This may not be relevant if only the current time at the time the value is converted is being logged, i.e. the data is never historical when it is being converted.

4 - And no offense, but to be perfectly honest I doubt this is ever needed; the number of people who read event log details that are uncomfortable with UTC can all fit into one minivan and still have room for the cooler full of beer they would be taking along with them!

Jim DeLaHunt on 4 Feb 2010 9:38 AM:

parkrrrr on 4 Feb 2010 10:33 AM:

parkrrrr on 4 Feb 2010 10:37 AM:

John Cowan on 4 Feb 2010 11:01 AM:

parkrrrr on 4 Feb 2010 11:08 AM:

Michael S. Kaplan on 4 Feb 2010 2:59 PM:

go to newer or older post, or back to index or month or day