FWIW, the problem is caused by different assumptions by Windows and OS X about the hardware clock (which is distinct from a software clock that the OS maintains once it's booted). Both systems use Coordinated Universal Time (UTC; basically Greenwich Mean Time, or GMT) internally; however, older Microsoft OSes (DOS and Windows 9x/Me) used local time internally, and so hardware clocks on PCs have traditionally been set to local time. When it boots, Windows NT and its derivatives (including XP, Vista, and 7) read the local time from the hardware clock and then set their internal clocks by adjusting this value using the time zone. Unix, and hence OS X, however, tends to assume that the hardware clock is set to UTC; they read it directly and set their internal clocks appropriately. Both OSes then convert their internal time (in UTC for both) to local time using the time zone setting. Therefore, with no special adjustment, if you dual-boot the two OSes, the clocks will be off by however far you are from UTC. (This amount may vary with Daylight Saving Time settings.)

Two solutions are possible: Make OS X act like Windows or make Windows act like Unix/OS X. I'm pretty sure that zephyroth's patch does the former. This page is one of many that describes how to do the latter. IMHO, adjusting Windows is the superior solution, since it means there will be little risk of problems when DST comes around. If the hardware clock is set to local time, then the hardware clock must be adjusted for DST changes. (UTC doesn't shift with DST changes; instead, computers adjust local time from UTC based on time zone data files.) Since Windows might try to do this automatically, you could easily get a double adjustment if you do it manually in OS X before booting Windows. If you're careful to keep Windows from making the adjustment, you'll still have to do it manually in one OS or the other. (I'm not sure offhand if a change in OS X will be properly sent to the hardware clock in a Hackintosh, though.) OTOH, there have been reports of Windows mysteriously resetting its clock interpretation, so making Windows treat the hardware clock as UTC might not be 100% reliable. I've seen this happen once myself, but a reboot fixed it.