Dahua NVR daylight savings

d5775927

Getting comfortable
Dec 11, 2019
359
308
Israel
I have two Dahua IPCs connected to a Dahua NVR (POE).
The NVR is configured to sync its clock from a NTP server on the same subnet (Raspberry Pi).
This week the time on the NTP server advanced in one hour (daylight savings), however, the NVR and cameras were not updated.
That is, this week the local time changed from UTC +2 to UTC +3, this change was reflected on the NTP server but not on the NVR or cameras.
This is the NVR config I use:
1648238124365.png
I want the NVR/cameras to have the exact time the NTP server has, is that possible somehow?
 
My current workaround is to change the timezone manually on NVR + each camera to a time zone of UTC+3.
This is not fun, since this needs to be repeated manually twice a year....
In my country the daylight savings do not apply on the same date every year, so I cannot use the builtin DST option.
 
Does DST where you are at correspond to like the 2nd week of March for example? If so, you can put it in that way instead of a date. Now if there is no methodology and someone simply pulls dates out of air, well then you gotta go in twice a year LOL
 
I have two Dahua IPCs connected to a Dahua NVR (POE).
The NVR is configured to sync its clock from a NTP server on the same subnet (Raspberry Pi).
This week the time on the NTP server advanced in one hour (daylight savings), however, the NVR and cameras were not updated.
That is, this week the local time changed from UTC +2 to UTC +3, this change was reflected on the NTP server but not on the NVR or cameras.
This is the NVR config I use:
View attachment 123232
I want the NVR/cameras to have the exact time the NTP server has, is that possible somehow?

Based on the photo and settings available in the software applications you need only define and set the following:

  • DST: Enable / Check Box
  • DST Type: Week
  • Start: March, Second Week, Sunday, 02:00 AM
  • End: November, First Week, Sunday, 02:00 AM
  • DST Bias: If this was present you would define it as 60 minutes

Change the time zone to what it's supposed to be in your location / region.
 
Mine works correctly set up like this...
Capture.JPG
 
Will not work for me, since the daylight saving date changes every year in my country.

Which country doesn't have it set up to be the same date or as an example 2nd Sunday of March? So like literally one year it could be February 28th and the next year April 7th? No set pattern?
 
Which country doesn't have it set up to be the same date or as an example 2nd Sunday of March? So like literally one year it could be February 28th and the next year April 7th? No set pattern?
Israel:
1648326654034.png
As if DST is not complicated enough.
 
Wow so sometimes it is the 4th Friday of March and Sometimes the 5th Friday, but not necessarily the last Friday of that month, but it is sometimes. What a mess LOL.
 
  • Like
Reactions: tigerwillow1
I don't see anything wrong here as stated early on you need only define the weeks of start ~ end. I just went through the calendar all the way to 2025. Based on what I saw and what has been provided by the OP DST Start is the 4th week. :thumbdown: If there's an edge case in some random year past 2025 for the DST end as I saw in one entry.

You'll just have to accept changing it to suite the technical requirements!

This isn't rocket science and the root cause is people are still stuck in the past . . . :facepalm:
 
I don't see anything wrong here as stated early on you need only define the weeks of start ~ end. I just went through the calendar all the way to 2025. Based on what I saw and what has been provided by the OP DST Start is the 4th week. :thumbdown: If there's an edge case in some random year past 2025 for the DST end as I saw in one entry.

You'll just have to accept changing it to suite the technical requirements!

This isn't rocket science and the root cause is people are still stuck in the past . . . :facepalm:
Having one day of clock out of sync is somehow acceptable by me, however, according to this:
1648585793192.png
The DST start date varies in 5 days (across 10 years) and DST end date varies in 6 days.
Which means, in the worst case I may have 11 days with clock out of sync.
I will probably write code (that will run on my Raspberry Pi) to manually change the time zone on the date of the clock change.
If I only change the time zone on the NVR i'm guessing it will not be enough?
 
I just reviewed the dates you provided and compared it to the system calendar. DST Start for all years up to 2029 always begins in the 4th week so using the week option in the NVR / DVR would solve the DST Start.

Unfortunately, the DST End has two years where it falls on the 5th week vs 4th week.

Not a lot you can to if you have to follow this standard to be honest but having to change only two years vs seven years isn't a bad compromise. Realistically you could just use the same for all years and accept the time will be off for a while until you go change it later on.

Setting up a reminder on your phone, calendar, etc . . .

As an aside I've seen a few people work around this problem by using BI or similar applications which allows them to embed the weather. The only difference is the they include the date & time in the same weather forecast. It's a break fix for a very rare edge case which I'm sure you can relate.

In 2022 DST should be removed because it has no material impact on the world today. :banghead:
 
When DST ends the clocks goes one our back, does it mean the NVR will overwrite that hour?
I mean, if on 2:00 the clock is updated to 1:00, does it mean one hour of recording is deleted?
The other case is simple (adding one hour - there will be an "empty" hour, which is fine).