No DST support?

pozzello

Known around here
Joined
Oct 7, 2015
Messages
2,270
Reaction score
1,117
we're not talking about a real ntp server, more of an NTP bridge...
the input side would be the local clock w/ TZ/DST adjusted,
and the output would be to (known pathological) NTP clients, that's all.
nothing about that precludes keeping the time sync'd from a real NTP server on the host pc.
sometimes two wrongs can make it right... :)
 

nayr

IPCT Contributor
Joined
Jul 16, 2014
Messages
9,329
Reaction score
5,325
Location
Denver, CO
well good luck, test it well first..

i could see it totally mucking up your recordings, depending on how its doing it.. if you jump back an hour with my ftp storage I think it would overwrite the last hour or less bad leave an hour blank.. as it stores files with local time and not GMT time.

I have a feeling nobody is going to put in hours and hours of coding effort and testing for something that takes a few seconds to do by hand, but hell I could be wrong.. I seen alot stupider apps.

fiddling with clocks can cause all sorts of unexpected behavior programmatically, ever hear of that Y2K thing?
 

CoreyX64

Pulling my weight
Joined
Mar 20, 2015
Messages
376
Reaction score
136
This is by far one of the stupidest:
https://appsto.re/us/OnVUX.i

Some examples, but these are mostly issues with incorrect dates:

On Windows, setting your clock/date wrong not only causes many of the system services to not work correctly, but you lose your status of "Genuine" Windows until the issue is corrected, which also denies you Windows Update access. (Windows 10 will never be genuine in 1998) I've seen this several times when someone has a CMOS battery die. Even though NTP is enabled by default on modern versions of Windows, for some reason it takes forever to actually update.

Another thing is SSL certs. On the dead CMOS battery note, it'll say Google has an SSL certificate that is not yet valid (in the future) because the clock rolled back to 1970 or something like that. (UNIX year 0). On Windows systems it usually depends on the BIOS/UEFI as far as how far back it goes.

As with most things, time (or in these cases, date) is critical.


Sent from my iPhone using Tapatalk
 

nayr

IPCT Contributor
Joined
Jul 16, 2014
Messages
9,329
Reaction score
5,325
Location
Denver, CO
Question: You guys are all using BluIris right? Why not just disable the cameras timestamps and have BluIris overlay timestamps.. then fuck whatever time your cameras have.. who cares if they are hours or months behind if you have Bi overlaying time.

seems like the obvious answer to your guys problem.
 

nayr

IPCT Contributor
Joined
Jul 16, 2014
Messages
9,329
Reaction score
5,325
Location
Denver, CO
ah suck..

all my poe voip phones are dst stupid, but I can update my asterisk config and restart all the phones for them to update.. if I had to go around to each one and change its time I probably would likely just leave them off for the winter months :p

could just set all your cameras to universal time (GMT) and calculate the offset in your brains manually, thats free :D
If you ever provide video to LEO just explain your religion does not believe in timezones, they cant argue with that.
 

pozzello

Known around here
Joined
Oct 7, 2015
Messages
2,270
Reaction score
1,117
right. most BI users with more than a handful of cams use DTD recording, which reduces CPU usage
by recording straight to disk without the decoding & re-encoding required to add any OSD-type text like a timestamp,
so we set up our cams to show the time and then BI just records that as-is.

but i'm coming around to your view here. the devilish detail here is how the client's would react to time jumping forwards or backwards
by an hour at the transitions. While they may take anythign at startup (no reference yet), many NTP clients will simply ignore a subsequent
response that's 'too far off' and even if they do accept/believe it, will not simply set the clock to that time, but gradually slew towards
it so as not to disrupt things that depend on the clock.

There's probably too much unpredictability in the various cam's NTP client behavior to make 'fudging' an NTP response producing
reliable (or even expected) results. Would have to do some testing to be sure, and probably not worth the effort. oh well...

IF we did build such a tool, the cams would probably at least have to be restarted for the change to take effect, mostly
negating the point.
 

fenderman

Staff member
Joined
Mar 9, 2014
Messages
36,897
Reaction score
21,250
If you record to bvr, you can add the time stamp back when exporting direct to disk video.
 

nayr

IPCT Contributor
Joined
Jul 16, 2014
Messages
9,329
Reaction score
5,325
Location
Denver, CO
If you record to bvr, you can add the time stamp back when exporting direct to disk video.
that would be ideal, I'd love to turn off timestamps entirely and still have the ability to export with them on there.. sometimes you get someone's face or activity behind a timestamp and it pisses me off.
 

TechBill

Known around here
Joined
Nov 1, 2014
Messages
1,770
Reaction score
1,175
Wouldn't if be easier just change the timezone in the camera like if you live in central time then set it to eastern time during the DTS season etc?

Bill
 

fenderman

Staff member
Joined
Mar 9, 2014
Messages
36,897
Reaction score
21,250
Wouldn't if be easier just change the timezone in the camera like if you live in central time then set it to eastern time during the DTS season etc?

Bill
This would require a manual change, which we are trying to avoid.
 

alphawave7

Getting the hang of it
Joined
Mar 22, 2014
Messages
573
Reaction score
94
Pretty sure Trump will do away with DST altogether...so I won't hold my breath for a firmware fix!
 

NVR990

Young grasshopper
Joined
Apr 28, 2017
Messages
71
Reaction score
16
that would be ideal, I'd love to turn off timestamps entirely and still have the ability to export with them on there.. sometimes you get someone's face or activity behind a timestamp and it pisses me off.
Is there any downside to Fenderman's suggested approach of recording to bvr (which I already do), then adding the time stamp back when exporting direct to disk video?

This approach is obviously simpler than using timesynctool, but I'm wondering if there some unrecognized benefit of using timesynctool? Redundancy for timestamp, perhaps?
 

fenderman

Staff member
Joined
Mar 9, 2014
Messages
36,897
Reaction score
21,250
Is there any downside to Fenderman's suggested approach of recording to bvr (which I already do), then adding the time stamp back when exporting direct to disk video?

This approach is obviously simpler than using timesynctool, but I'm wondering if there some unrecognized benefit of using timesynctool? Redundancy for timestamp, perhaps?
the downside is that if your database becomes corrupt you wont be able to add the time back..also, when viewing recorded video its nice to have the time on the video itself...time sync tool takes a few minuets to setup...
 

NVR990

Young grasshopper
Joined
Apr 28, 2017
Messages
71
Reaction score
16
the downside is that if your database becomes corrupt you wont be able to add the time back..also, when viewing recorded video its nice to have the time on the video itself...time sync tool takes a few minuets to setup...
Makes sense. Thanks!
 

wxman

Pulling my weight
Joined
Feb 15, 2015
Messages
631
Reaction score
163
Location
Southern United States
There should be a simple javascript code that could be added to the firmware. I'm trying to view over the time setting codes now, but I have very little javascript experience, so I can only make partial sense out of it...If someone is familiar with javascript, it seems like it would be fairly easy to add a mathematical time adjustment within a certain date/time range (or even a script to change time zones to the neighboring time zone when you need an hour difference)...
 
Top