views:

273

answers:

2

My application converts past and present dates from local time to UTC.

I need to ensure I will honor any future DST updates to Windows while still correctly handling past dates.

The application is written in C++ and is running on Server 2003.

Options I've researched:

So...

  • ... is anyone else using the raw registry solution to do this?

  • ... any other suggestions?

(edit: found out dst_calc_engine doesn't support DST updates)

A: 

You could use gmtime() and localtime() for dates in 2007 and later (and take advantage of Windows DST updates), and use Boost or one of the other solutions you mentioned to use the correct DST rules for 2006 and earlier.

Jim Lewis
Unfortunately, gmtime() and localtime() only respect the current DST settings. If Windows' DST methods are updated in 20xx, gmtime() and localtime() will be invalid for dates between 2007 and 20xx.I've updated the question to note this.
mskfisher
Bummer! Yeah, that puts you in a tough situation -- you want some aspects of the Windows DST updates, but not others. I'm out of ideas then -- I hope you find something that works for you.
Jim Lewis
+1  A: 

I think I'd prefer to re-implement GetTimeZoneInformationForYear and possibly GetDynamicTimeZoneInformation based on the information in the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones.

That way, your code will follow Windows updates and you can swap the dirty code out for the actual implementation on up-level platforms.

Since you don't want to use an external database, I think no other options are viable.

Kim Gräsman
I like the idea of re-implementing it with an identical signature to the replacement so that the native API could be a drop-in replacement when we move to Server 2008.
mskfisher
There's (at least :) one risk associated with that strategy, though. These two functions are pretty new -- if bugs are found in them, and they are updated along with timezone data in a new format, your functions could be broken. It doesn't seem very likely, but it's always a risk when using "under-the-API" data, like the registry backing for the timezone info.
Kim Gräsman