|
StuartMW
Premium Member
2013-Mar-11 12:19 pm
MSE, DST and scheduled scansI have MSE configured to run a scheduled scan at 1am every night. With the changeover to summer time , yesterday, the scan ran at 2am instead (i.e. 1am standard time) last night. I changed the schedule to another time and changed it back to 1am so I'll see tonight if it runs at the scheduled time. BTW it did this on two machines.
MSE version is 4.2.223.0 |
|
|
What am I missing here? Why shouldn't the scan run an hour off schedule if you hadn't changed it prior to its running and after daylight time had changed? I would think that there are many programs that run, according to time, that need to be changed, not just MSE, if one is changing time. Fortunately, we don't, so nothing to think about here. But what did I miss? Are you just trying to remind everyone or what? |
|
1 edit |
StuartMW
Premium Member
2013-Mar-11 2:50 pm
Well I've asked it to scan at 1am so that's what I expect it to do regardless of DST. Think of it just like an alarm clock. You don't reset those at the time changes.
My satellite TV receiver used to shift scheduled tasks by an hour every time DST came into or went out of effect. Unless you manually changed them you'd miss programs (which run at local times). Presumably many complained because it no longer does this.
Scheduled tasks (I used to work for a company that sold equipment that did this) are tricky when it comes to time changes. For example when springing forward the time goes from 1:59am to 3:00am. What do you do if something is scheduled at 2am? Likewise in the fall there are two 1am's (time goes from 1:59am to 1:00am). |
|
|
BlackbirdBuilt for Speed Premium Member join:2005-01-14 Fort Wayne, IN |
to StuartMW
To add to the confusion, I had exactly the opposite situation as you did. I have a short file backup program (~8 minutes run time) that is set to automatically run daily at 2:30am. It ran at 2:30 every day of the week prior to the Sunday-morning 2am time change, but Sunday morning it's logged as running at 1:30am. This morning (Monday) it again ran at 2:30am.
One has to love the perfect consistency, repeatability, and logic of digital technology. Maybe someday I'll be blessed to actually see it... |
|
La LunaFly With The Angels My Beloved Son Chris Premium Member join:2001-07-12 New Port Richey, FL |
to StuartMW
My MSE scan ran at 3:15AM instead of 2AM? Is that the start time or the finish time?
Doesn't matter to me, it's the only thing that runs at those times anyway. |
|
|
StuartMW
Premium Member
2013-Mar-11 3:46 pm
said by La Luna:Is that the start time or the finish time? Start time. Also MSE randomizes the actual start time. Note that the schedule time says "Around". I consider this schedule time-shift a MSE bug although not a serious one. |
|
StuartMW |
to Blackbird
quote: Time is an illusion. Lunch time doubly so.
Douglas Adams
Douglas Adams would've been 61 today. |
|
La LunaFly With The Angels My Beloved Son Chris Premium Member join:2001-07-12 New Port Richey, FL |
to StuartMW
Yep, you'd think it would be aware of the DST change. I guess it isn't. |
|
jimkyleBtrieve Guy Premium Member join:2002-10-20 Oklahoma City, OK |
to StuartMW
If it actually did run at 1 a.m., that was an hour before the time change. If your system keeps "universal" time on the RTC and the o/s automatically corrects that to your local time zone for display (as many of them do), then it would show in the log as 1 a.m. until the time change cut in, and then would show as 2 a.m. -- as it did. I suspect this is simply a problem in understanding what's going on behind the curtain.
Of course that doesn't explain some of the other reports in this thread... |
|
dave Premium Member join:2000-05-04 not in ohio |
dave
Premium Member
2013-Mar-11 5:51 pm
I understood the OP to say that it ran at the wrong time in the early hours of Monday morning ("2am last night" being what I would call "2am today"), in which case the time change a day previously would not have caused the effect in the way you describe it.
But maybe I misunderstood when "2am last night" was. |
|
|
StuartMW
Premium Member
2013-Mar-11 6:08 pm
It ran around 2am Monday March 11th 2013. Hopefully that is unambiguous. That is one day after DST went into effect.
Windows (for a decade or more) has used UTC time internally. Displayed timestamps, for files etc, are calculated using your timezone and DST from the UTC base. That's why file timestamps change if you change timezones or at DST transitions.
That said, and I used the alarm clock analogy above, a scheduled event should run at the designated time. If I set my alarm clock to go off at 6:00am it does regardless of DST (assuming I adjusted the time). |
|
dave Premium Member join:2000-05-04 not in ohio |
dave
Premium Member
2013-Mar-11 6:44 pm
Oh, I agree. And in any case, while I know that an absolute date-and-time is stored in UTC (as a number of 100nS ticks from 1601), it's unclear to me how something like "2 AM" could be represented as UTC or not-UTC.
I mean, it's sensible to store is as "2 hours worth of time units" but not as far as I can see sensible to store it as something like "7 hours worth of time units".
I checked MSE on the Win7 system I am using here. It's configured to run at 2:00 AM, "last scan ran at 3:54 AM". Maybe I have the same disease. |
|
1 edit |
StuartMW
Premium Member
2013-Mar-11 6:51 pm
said by dave:...it's unclear to me how something like "2 AM" could be represented as UTC or not-UTC. My guess it that MSE stores a UTC timestamp for it's schedule when set. Thereafter when the schedule runs it adds 24 hrs (+/- a randomization) to that value. That would explain the behavior we're seeing. PS: From a programming standpoint this is really easy to implement. It's also very easy to check when to run. • Get system UTC time. • Get next run time (in UTC). • Is run time >= system time run. • If yes, add 24hrs to system time and save as next run time then run a scan. This methodology gets around timezone/DST change issues since its based on elapsed time. The disadvantage is that stuff may run at a different local time. |
|
StuartMW |
StuartMW
Premium Member
2013-Mar-12 9:44 am
FYI changing the scan time and setting it back did the trick. MSE scanned around 1am last night. |
|