In the current Android app doing video playback from a V3 camera, the time on the slider bar does not match the time on the video (when selecting a time before the “spring forward”). The video is an hour ahead of the slider bar for yesterday’s footage (SD Card footage, CAM+ is fine). There is also a gap of unrecorded footage on the V3 cameras between 1 a.m. and 3 a.m. on my V3 cameras (SD card). This may be just the way the developers handle DST, I don’t know.
1 Like
I checked all my cameras today to make sure they picked up the time change, even checked the Rules. But I forgot to check the SD card! 
The 1 to 2 AM blank spot doesn’t sound logical, but I think you are right in it is the way the Devs chose to handle DST.
I suspect the camera only has 1 time vantage point – now. So when you back up to what was 1 AM yesterday, the time stamp on the video will tell you that you are approaching 2 AM, because that’s what it recorded. At 2 AM it jumped to 3 AM, and all the non-DST footage was mathematically considered an hour earlier (because it was, if you compare it to now, DST). So you end up with a gap from 1-3 AM.
Wonder if that can be fixed.
Also, I notice there is a gap of an hour to the end of the blue timeline. So it is 9-something AM for me right now, but the blue ends an hour back at 8-something. Wonder if that will correct itself, or if we need a fix.
@WyzeBaohua, can you make this thread known to your people?
3 Likes
Yeah, I am missing the 1-3am portion of video too, and my slider bar is an hour off from the DST time stamp by -1 hour. It is interesting though that the gap on the slider bar is only 1 hour in width though. 2am to 3am is completely missing from the bar…like a time warp happened. 
But, all the video is there. Didn’t miss a second. Playing back at 1;59:59 DST timestamp on the video (12:59:59 on the spring forward slider bar) jumps over the dead slider bar area at exactly 2AM straight to 3AM new time time stamp footage. So it did record everything. The only time you see the dead air screen is if you stop the slider bar in the “missing” time.
I think a better solution would be to just scrap DST!
1 Like
I agree it is a mess with the SD time.Same issue as above, zero recorded between 1-3 AM and one hour ahead on the time line bar. I thought this was 2022 not 1922 
Actually, everything WAS recorded. All the video is there if you look at the time stamp on the video rather than the slider bar it jumps from 1:59:59am to 3:00:00 am which is exactly what was supposed to happen when the clocks jumped forward. Not a second missed.
The issue is with the app not being able to deal with a ‘missing hour’ when labeling the time on the slider bar because that is set from the phone time or server time, not from the video timestamp time. It can’t leave the DST time alone when also pushing an hour forward on the same slider bar. It’s all or nothing. This is just an anomaly in the slider bar time source coding, not a loss in video recording.
I can’t wait until 6 months from now to see what happens when it tries to delete an hour of video!
Yes all the recordings are there I checked earlier. It just seems silly to me, this is not the first year of daylight savings time 
.Even my dash cam is smart enough to change to the correct time….
I can understand a two hour gap, but like you all, I have a two hour gap. Here’s where it gets strange. I looked at a bunch of my cameras. All of the V2 and original Pan cameras shows the gap at exactly 0100 - 0300. All of the V3 cameras that I looked at, the recording stops at 0133 (timeline) / 0233 (shown on video). Video resumes at 0333 (both timeline and recorded video).
I think @Newshound time explanation makes the most sense…
Since know what time I came home last night (and several of the cameras show where I park), I went back in the timeline to find when I got home. Timeline says I got home at 2216, and the recording video says 2316 - which is correct. On the other side of the time change, I know what time my landscape lighting turned off this morning, and the timeline and recorded video correctly shows that the lights went off at 0652. I get an E-Mail from the computer that is controlling the lights, so I know when that was.
The only reason I noticed it was that someone knocked my mailbox off the post last night.
While I was reviewing the footage the time discrepancy jumped out quickly, then I noticed the gap.
I thought for sure it was going to happen during that gap (which was not really a gap at all).
The Lorex system caught it, but it was in black and white, luckily we got a clean shot of the culprit on both Wyze and Lorex (in color on two V3 cameras)!
I agree that we should leave time alone, but I want this time (the sprung forward one)!
I wonder what happened to Wyze customers in Arizona this time?
Time line on my V3 appears to be back to normal again, correct times are showing 
1 Like
My SD card timelines are back to normal too, showing blue up to the current time.
Both V3s and V2s.
I have some new DST oddities.
I have a switch schedule set to turn off a switch at Sunset. Yesterday after the time change it fired off without change, which is now an hour early. I have no Sunrise equivalent on that device. Log in 500388.
To test Sunrise and Sunset rule schedules, I have a short clip uploaded to the cloud at sunrise and sunset from my front and backyard cameras. Both are executing at the proper times, but Sunset is firing TWICE on BOTH cameras. Log of one of those two cameras is in 500393.
FYI -
My switch schedule set to turn off a switch at Sunset fired properly last night, so thanks for fixing that!
The test clips I upload to the cloud at sunset from my front and backyard cameras both are still are executing TWICE on BOTH cameras, however. A couple minutes apart. I have re-saved these rules to see if that helps. Log above.
EDIT, next day: The test clips I upload to the cloud at sunset are still executing twice, so I deleted and re-added one of them. Stay tuned.