›

Problem with Daylight Savings Time change

Don
in Acrosync for Windows
It appears that Acrosync did not handle the DST time change properly. I have Acrosync running on a WIndows 2012 server as a service. I have two jobs scheduled to run every night that both backup files to a NAS. One runs at midnight and the other at 03:00 (3 AM). Here is when they ran:

Sat/Sun 00:00 (midnight) - correct time to run
Sun 02:00 (2 AM) - incorrect time to run, an hour too soon
Sun 03:00 (3 AM) - correct time to run
Sun 23:00 (11 PM) - incorrect time to run, an hour too soon

At this point I stopped the Acrosync service and restarted it. It was a little past midnight that I performed the stop/start. The next run was at:

Mon 03:00 (3 AM)  - correct time to run.

I don't know how Acrosync handles it scheduling but it doesn't appear to be correct. I am running version 1.6 build 582.

Comments

  • Don
    Update - Still not working correctly. The midnight run happened at 11 PM again. I checked the schedule on the job and it is set for 12:00:00 AM. Time, time zone, and DST settings are correct on the server also.
  • Don
    Update 2 - the midnight job also ran at midnight. So it is running at 11 PM and midnight. How do I cancel the 11 PM job when I don't have one scheduled?
  • gchen
    What are the values of ScheduleFlags and ScheduleSeconds of those 2 profiles in the registry under HKLM\Software\Acrosync\AcrosyncClient?
  • Don
    Profile_0
    No entries

    Profile_1 (Should be the 3 AM job)
    Scheduled = 1
    ScheduledFlags = 254
    ScheduledSeconds = 10800

    Profile_2 (Should be the 12 AM job)
    Scheduled = 1
    ScheduledFlags = 254
    ScheduledSeconds = 0

    Profile_3 (looks like an old on demand job that was deleted a while ago that was backing up the same directory as the 3am job)
    Scheduled = 0
    ScheduledFlags = 254
    ScheduledSeconds = 0

    Also under the AcrosyncClient key the following values are present:
    AutoStartProfiles = 1 2
    Profiles = 1 2
  • gchen
    I think if you stop (not pause) the service and restart, it will get the scheduled time right.  The bug only happens when it crosses the daylight saving time change.  When the service get restarted, it will reset the scheduled time.
  • Don
    I already tried that (see first post). I will try a reboot of the server.
  • Don
    OK, looks like a reboot solved the issue. Jobs ran at their scheduled times. Still a bug somewhere that caused this to happen.

    Thanks
  • gchen
    I know the bug is in the code to increase the scheduled time by one day:

        scheduledTime += 24 * 3600;

    However, once the service is restarted it will recalculate scheduledTime, so I don't know why in your case it still didn't get it right after a reboot.  And it should never schedule the job at two different times in the same day.


  • Don
    It didn't get it right after I restarted the service but it did get it right after a reboot.
  • gchen
    sorry, I meant why it didn't get it right after a service restart.
Sign In or Register to comment.