Prompted by a bug report regarding the new DST rules I had a closer look how localtime() determines DST on Windows. Below is my analysis of the sorry state of affairs, as far as I can tell. I guess for the vast majority of Windows users this just means that DST will be wrong for older timestamps. I'm not sure how important that is though. Providing a proper workaround probably means that we would have to use the DateTime::TimeZone module within localtime(). ===================================================================== The daylight saving time (DST) for the localtime() function is determined by the C runtime library function of the same name. This function has 2 different operating modes: 1) The TZ environment variable has been set. In this case MSVCRT calculates DST itself, based on the USA rules. The latest released version (as of (March 5th 2007) of MSVCRT.dll has not yet been updated for the 2007 DST rules. The localtime() function will still apply the old rules to 2007. Microsoft claims to have a hotfix for this, that is available from Microsoft Customer Support Services only: http://support.microsoft.com/kb/932590 2) The TZ environment variable has *not* been set. In this case MSVCRT retrieves the DST transition times from the GetTimeZoneInformation() API: http://msdn2.microsoft.com/en-us/library/ms724421.aspx This API only provides the transition times according to the *current* DST rules. There is no database of historical transition times. That means that localtime() applied to previous years will use the new transition times even for old timestamps. Windows Vista (and Longhorn Server) support a new API called GetDynamicTimeZoneInformation() that implements a database of historic DST rules. It is not known if the hotfix mentioned above will make use of this API when running on Vista. ===================================================================== Cheers, -JanThread Next