Daylight Saving Time - Computing - Microsoft Windows

Microsoft Windows

As with zoneinfo, a user of Microsoft Windows configures DST by specifying the name of a location, and the operating system then consults a table of rule sets that must be updated when DST rules change. Procedures for specifying the name and updating the table vary with release. Updates are not issued for older versions of Microsoft Windows. Windows Vista supports at most two start and end rules per time zone setting. In a Canadian location observing DST, a single Vista setting supports both 1987–2006 and post-2006 time stamps, but mishandles some older time stamps. Older Microsoft Windows systems usually store only a single start and end rule for each zone, so that the same Canadian setting reliably supports only post-2006 time stamps.

These limitations have caused problems. For example, before 2005, DST in Israel varied each year and was skipped some years. Windows 95 used rules correct for 1995 only, causing problems in later years. In Windows 98 Microsoft marked Israel as not having DST, forcing Israeli users to shift their computer clocks manually twice a year. The 2005 Israeli Daylight Saving Law established predictable rules using the Jewish calendar but Windows zone files cannot represent the rules' dates in a year-independent way. Partial workarounds, which mishandle older time stamps, include manually switching zone files every year and a Microsoft tool that switches zones automatically.

Microsoft Windows keeps the system real-time clock in local time. This causes several problems, including compatibility when multi booting with operating systems that set the clock to UTC, and double-adjusting the clock when multi booting different Windows versions, such as with a rescue boot disk. This approach is a problem even in Windows-only systems: there is no support for per-user timezone settings, only a single system-wide setting. In 2008 Microsoft hinted that future versions of Windows will partially support a Windows registry entry RealTimeIsUniversal that had been introduced many years earlier, when Windows NT supported RISC machines with UTC clocks, but had not been maintained since.

An interesting effect can be observed with file time properties. The NTFS file system used by recent versions of Windows stores the file with a UTC time stamp, but displays it corrected to local—or seasonal—time. However, the FAT filesystem commonly used on removable devices stores only the local time. Consequently, when a file is copied from the hard disk onto separate media, its time will be set to the current local time. If the time adjustment is changed, perhaps automatically (daylight saving) or if the user selects a different time zone, then when the timestamps of the original file and the copy are compared there will be a difference. This may be verified (without having to wait for the next equinox) by copying a file, removing the media, adjusting the time zone options, reconnecting the media, and viewing the details of the file and its copy. The same effect can be observed when compressing and uncompressing files with some file archivers. It is the NTFS file that changes seen time. One can store a file listing and check it after the DST change. This effect should be kept in mind when trying to determine if a file is a duplicate of another although there are other methods of comparing files for equality like using checksum algorithms.