Daylight Savings Time in LabVIEW for Dates Before Feb 2007 May Be Calculated Incorrectly Primary Software: LabVIEW Development Systems>>Professional Development SystemPrimary Software Version: 1.0 Primary Software Fixed Version: N/A Secondary Software: N/A
Problem: How do I calculate a correct Daylight Savings Time (DST) for timestamps whose date is before February 2007 in Windows 2000/XP? Solution: With the "Energy Policy Act of 2005", the effective dates for Daylight Savings Time (DST) have changed. This causes problems with Windows reporting historical dates appropriately. For example, prior to Feb 2007, DST in the United States for the “Central Standard Time” time zone was calculated with the following heuristic: DST would start the first Sunday of April and end the last Sunday of October. After Feb 2007, to comply with the "Energy Policy Act of 2005", Microsoft released a Windows update that changed this heuristic to be as follows: DST would start the second Sunday of March and end the first Sunday of November. Since this heuristic is global to the country and time zone, all historical dates are affected by this change, and may produce incorrect results. Here is a simple example for Central Standard Time in the USA: 2003 DST Begins at 2 a.m April 6 DST End at 2 a.m October 26 2004 DST Begins at 2 a.m April 4 DST End at 2 a.m October 31 2005 DST Begins at 2 a.m April 3 DST End at 2 a.m October 30 2006 DST Begins at 2 a.m April 2 DST End at 2 a.m October 29 2007 DST Begins at 2 a.m March 11 DST End at 2 a.m November 4 The table above describes when DST started and ended for “Central Standard Time” (CST) in the United States. If a user drops a LabVIEW date time rec on the front panel with the date "March 31, 2005, 12:00AM (midnight)", and then drops a "Date/Time to Seconds" primitive to and tries to convert the LabVIEW Date/Time rec to a timestamp, the conversion fails because the OS reports back that March 31, 2005 is part of DST when in fact it is not. LabVIEW reports a bad conversion of 1AM when in fact the expected result is midnight. If a user drops a "Seconds To Date/Time" primitive and tries to convert their timestamp to a LabVIEW Date/Time rec, the conversion fails because the OS reports back that March 31, 2005 is part of DST when in fact it is not. Since Microsoft's DST heuristics is a global heuristic for that particular time zone in that particular country, it has a bad effect on historical date. That is, the new DST heuristics are being applied to old legacy dates, producing small errors for certain dates. These problems only occur when doing a conversion from/to the LabVIEW Date/Time rec to/from the 128-bit timestamp and only for dates that fall between the second Sunday of March to the first Sunday of April and for dates that fall between the last Sunday of October and the first Sunday of November. Microsoft is not officially supporting any fix for Windows XP and has addressed some of the issues in Windows Vista. Related Links: Attachments:
Report Date: 11/08/2007 Last Updated: 11/08/2007 Document ID: 4F7J62F |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
