The DST bug is difficult to resolve reliably. Here are some of the variables that need to be taken into account that can affect the results of retrieving a file time: different APIs can return different results, different runtime functions can return different results, state of the TZ environment variable can affect results, different versions of Windows and WINE can return different results, bugs in different versions of runtime/API calls need to be taken into account, FAT/NTFS can return different results, quirks such as
GetFileTime reading from a UTC cache that only gets reset when Windows is restarted, and so on.
To get around all of these DST-related issues, most backup applications have a simple "DST" option that ignores file time changes that occur exactly one hour before or after. Some backup applications actually have several options just to handle DST to different tolerance levels but few of them attempt to resolve the issue on a technical level. The latest mIRC beta ignores file time changes one hour before or after - which should resolve the twice yearly issues that users report - but at the expense of not correctly detecting file time changes exactly one hour before or after.
