SyncToy confused after change in daylight savings time? RRS feed

  • Question


    I have a disc that I use to move files between home and work. Generaly less than 1% of the files change each time I sync. The last sync took place on an XP system at home earlier today. The same folders normally sync fine with my Vista box at work, but today SyncToy is showing the that the files on Vista all have timestamps 1 hour before those on the external drive. We've just switched from British Summer Time to GMT so the the clocks went back 1 hour last night. Any chance the next build of SyncToy could recognise when this occurs as frankly I can't see the point of overwriting 30,000 files with identical copies of themselves....



    Sunday, October 26, 2008 11:28 PM


All replies

  • Same problem here: I use SynToy for synching between a laptop and a desktop. Unfortunately I was working over the weekend so I am left with one great big mess trying to sort out by hand. Interestingly ECHO seems to be unaffected by the problem - despite the files on the PC showing as being 1 hour ahead of those on the memory stick it didn't try to copy all those files across again.


    Monday, October 27, 2008 10:29 AM
  • Please Please release a fix for the daylight savings time error. It has been a royal headache--I'm missing files now, etc.




    Tuesday, November 4, 2008 6:21 AM
  • Hi Mark


    What version of SyncToy are you using? Is it a Beta version? 


    Maria del Mar Alvarez - MSFT


    Thursday, November 20, 2008 9:08 PM
  • I'm running SyncToy 2.0 Beta Version build 10/12/2007 @ 1:10:32 PM. I suspect the issue is related to the way Vista handles requests for file timestamps before & after a change in DST as my XP system didn't think there had been any changes. In the end I gave in and let it overwrite all the files.





    Friday, November 21, 2008 7:25 PM
  • The daylight savings issue found on SyncToy 2.0 Beta was fixed in the in the official SyncToy v2.0 release.   You can download the official release from http://www.microsoft.com/Downloads/details.aspx?familyid=C26EFA36-98E0-4EE9-A7C5-98D0592D8C52&displaylang=en


    Before upgrading, please overview the Instruction section as it includes important information for users upgrading from SyncToy 2.0 Beta and SyncToy 1.4.


    Maria del Mar Alvarez Rohena - MSFT

    Friday, November 21, 2008 8:05 PM
  • Thanks for this. I'd obviously missed the transition from beta to full release.



    Monday, November 24, 2008 6:24 PM

    SyncToy V. Built 12/08/2008 14.07.12. I didi not upgraded from any other older or beta version, I started with V.2.

    Issue of the one hour forward not solved going back to standard time. SyncToy does not recognize that there is no change but it has with the switching form DST. Thinks there are again all files never changed since 2007 are different. I am using WinXP SP3.


    Edit: I noticed that the timestamp problem seems to exist only with those older files before 2007 that I never syncronized in the past because I knew they were exactly the same in both folders. Do you think that I should go ahead and overwrite all of those hundreds of files (sigh!) so that SycToy will finally realize from then on that even after switching to DST those files are the same?

    Sunday, December 21, 2008 12:48 AM
  • The daylight savings issue found on SyncToy 2.0 Beta was fixed in the in the official SyncToy v2.0 release.  

    First time syncing for a couple of months, running the official synctoy v2.0 release, and still seeing the daylight savings change problem. All files are being copied as I am typing, and will take most of the day to complete.
    Thursday, December 9, 2010 12:33 PM
  • I too have the Sync Toy Daylight Saving problem where twice a year it insists on re-copying everything.  This is especially annoying as I live in Arizona and we don't observe Daylight Saving Time, thus the computer clocks don't change, but Sync Toy still pushes a full backup...

    Sync Toy 2.1 

    XP Pro

    Wish Microsoft would fix this as Sync Toy is great otherwise.

    Saturday, December 18, 2010 11:59 PM
  • Still the same bug. Shame, 3 years passed.
    Thursday, March 31, 2011 4:37 PM
  • Confirming the same bug, version
    Wednesday, January 11, 2012 2:27 PM