No DST support?

P

pozzello

Known around here
Oct 7, 2015
2,270
1,117
Just went thru the config on all my Hikvisions and set the DST start time to second Sunday in March
(vs default first Sunday in April) and they are all now showing the correct time after our DST event here in the US.

Even the $20 720p IP cams I use for test setups have a decent GUI for setting the DST start/end time in the CMS sw,
as that varies all over the globe and even from year to year in any particular location...

But the Huisun/Imporx V2 miniptz doesn't seem to support DST time adjustments at all, that I can tell.
The hik's have this in the advanced config / system / DST tab, but I haven't found any equivalent config
on the Huisun/Imporx. Stepped thru all the options in preset 95 also (which is where they hide their
'advanced' settings)

Anyone know if/where they do this? Or do we petition for a firmware update/fix?
I guess having to set fake timezone twice a year (Mountain time for me on the west coast)
to display the correct time isn't that big of a deal, but still...

[TABLE="class: deviceTable"]
[TR]
[/TR]
[TR]
[TD="class: deviceInfoTd"]Program Version[/TD]
[TD="class: deviceInfoTdWhite"]V2.0.1 Build 201602010919S[/TD]
[/TR]
[TR]
[TD="class: deviceInfoTd"]Control Version[/TD]
[TD="class: deviceInfoTdWhite"]MiniPtz_V1.0.2_build201512011507[/TD]
[/TR]
[TR]
[TD="class: deviceInfoTd"]Web Page Version[/TD]
[TD="class: deviceInfoTdWhite"]1.1.1 Build 20160201[/TD]
[/TR]
[TR]
[TD="class: deviceInfoTd"]Plugin Version[/TD]
[TD="class: deviceInfoTdWhite"]1.0.4.41[/TD]
[/TR]
[/TABLE]
 
Last edited by a moderator:
The time server on Hikvision devices has always been a bit funny. On the cameras themselves I have never been able to get them go work, they rely on the NVR to relay time to them. Same with the NVR though, it has trouble connecting to a time server, so I've had to manually sync the time, set the DST to auto, and it does the rest. I do flip it back to connecting to a time server in hopes that at some random point in time the NVR decides to connect and sync with that. I've tried many different time servers, same result. Whatever I am doing works for now, but it's trickery. It's not working out of the box.

As far as Huisun is concerned, I haven't worked with these cameras before so I can't say. In theory, a camera doesn't need to know DST settings, only needs to know the time server and time zone. The server should do the adjusting, and devices synced with it should follow, in theory.


Sent from my iPhone using Tapatalk
 
CoreyX64 said:
As far as Huisun is concerned, I haven't worked with these cameras before so I can't say. In theory, a camera doesn't need to know DST settings, only needs to know the time server and time zone. The server should do the adjusting, and devices synced with it should follow, in theory.
Click to expand...

I agree, but that does not seem to work. Tried a refresh on the time server and it made no change. Maybe the time server is still set for April??

I guess we will know if it jumps ahead an hour next month.
 
"In theory, a camera doesn't need to know DST settings, only needs to know the time server and time zone."

this is not true. NTP time servers tell you the precise time in UTC timezone only (== GMT w/no DST).
it's up to the client to apply proper offset (+/- timezone +/- any DST adjustment)

[edit: That said, you can run your own NTP server and set it to 'fudge' the time for you, as suggested by @nayr.
That's a good solution since in addition to providing a 'fix' for lame cams, it keeps all your cams in good sync
with your BI/server and also reduces load on the internet time servers, although they can handle it really...]

the huisun miniptz does not appear to support automatic DST offsets at all.
I'm hoping i'm wrong about that and maybe there's a hidden UI for this (preset xx?)
but i know for certain that NTP time servers don't know how you want to do DST.
 
Last edited by a moderator:
pozzello said:
"In theory, a camera doesn't need to know DST settings, only needs to know the time server and time zone."

this is not true. NTP time servers tell you the precise time in UTC timezone only (== GMT w/no DST).
it's up to the client to apply proper offset (+/- timezone +/- any DST adjustment)

[edit: That said, you can run your own NTP server and set it to 'fudge' the time for you, as suggested by @nayr.
That's a good solution since in addition to providing a 'fix' for lame cams, it keeps all your cams in good sync
with your BI/server and also reduces load on the internet time servers, although they can handle it really...]

the huisun miniptz does not appear to support automatic DST offsets at all.
I'm hoping i'm wrong about that and maybe there's a hidden UI for this (preset xx?)
but i know for certain that NTP time servers don't know how you want to do DST.
Click to expand...

I thought about that shortly after posting, that the UTC to GMT-x conversion is done in the device itself not on the server. (Hence "theory") That makes sense. Why give the server any more load than necessary?

In the case of Hikvision recorders it acts as a NTP relay. (Er...client and server) It maintains its own ToD then simply spits that out to the cameras (assuming all Hikvision, no idea if that's something ONVIF or other non-HV brands support with a HV recorder). Point being the cameras never NTP out to WAN, it's strictly internal in the NVR's private network. Or for all I know, the NVR just manually sets the camera time to each one, and refreshes it every so often (not using the NTP protocol). I don't care enough to WireShark it to find out, because it works very well.

Whether BI offers something like this (I'm guessing no) or there's 3rd party Windows/Linux software to mimick this feature, I would not know as all of my stuff is strictly embedded. It would be cool if it did though, but obviously you need some support from the camera for that to even be of any use.


Sent from my iPhone using Tapatalk
 
Last edited by a moderator:
CoreyX64 said:
The time server on Hikvision devices has always been a bit funny. On the cameras themselves I have never been able to get them go work, they rely on the NVR to relay time to them.
Click to expand...

That is strange...I've never had a single problem with Hikvision cameras connecting to time.windows.com on a regular basis.
 
I've tried Windows, Apple, NIST, the NTP pool, several. When the camera is naked and standalone, I've waited forever to watch the clock change. I've seemingly never been able to get it to go. I haven't messed around with it much because my patience ran out, but the NVRs seem to do fine with it. Those also have a CMOS battery so for all I know it's just maintaining what it has. But lately they all seem to be spot on accurate. The next 3145 dome that I play with I'll give it a try for kicks, see what happens. I do know that hitting the NTP test button failed many times before.


Sent from my iPhone using Tapatalk
 
A timeserver like timesynctool that could auto adjust to dst would be fantastic as it would save the hassle of setting each camera up independently for dst.
 
Does anyone know how to enable NTP server in Windows 10? I'd like to have all my Hikvisions query time from their BI server PC.
 
@nayr, i checked that out, but it doesn't seem to have any frobs to 'adjust' the time it serves.
it's just a passthru/proxy for ntp, unless i'm missing something.

as @fenderman pointed out, it would be cool for such a proxy to be configurable to 'fudge' the NTP timestamp
to compensate for lame (or unconfigured) cameras (like Hiks that default to beijing timezone and dst off,
or the huisun/imporx that don't seem to support DST, etc...) If you're installing a bunch of 'em, that's one
less thing you'd need to set in each cam's config...
 
Last edited by a moderator:
thats not how NTP works.. protocol expects TZ settings to be applied locally.

If time is so critical updating it twice a year is unreasonable, then buy better cameras.
 
yes, nayr, i know that's how NTP works. i'm just thinking of a 'creative' use for it,
since the protocol wasn't very well thought, imo. It should really carry some
information with it about whether the timestamp has been localized or not, and
if not, then the client can apply TZ/DST offsets, while if so, the client would just take it as-is.

since we're not going to redesign this ancient internet protocol, a clever 'server' that knows
its clients could be used to facilitate installation and upkeep. Yes, it would be hack, but might be useful...
 
  • Like
Reactions: fenderman
It wouldn't hurt to send email to Huisun to request this feature.
 
klasipca said:
It wouldn't hurt to send email to Huisun to request this feature.
Click to expand...

DING DING DING!! correct answer we have a Winnar!!!

Putting a NTP Server on the network that purposely lies to the clients because they are too stupid to handle DST is not likely going to end we'll... Lets say you have a mix and match cluster fuck, are you going to run 2 time servers.. one non-fucked one for cameras that can handle DST and one fucked one? How does your NTP Server know when its supposed to lie and when its not supposed to? Are you going to have to manually alter that time server twice a year now too?

I think my 7th grade programming class we worked on calculating timezones and DST.. you got exactly what you paid for when you got a $150 PTZ.. $149 worth of hardware, and $1 worth of software.

how many of these did you buy that changing DST twice a year is more work than writing your own software to bust NTP Specs?
 
Last edited by a moderator:
nayr said:
DING DING DING!! correct answer we have a Winnar!!!

Putting a NTP Server on the network that purposely lies to the clients because they are too stupid to handle DST is not likely going to end we'll... Lets say you have a mix and match cluster fuck, are you going to run 2 time servers.. one non-fucked one for cameras that can handle DST and one fucked one? How does your NTP Server know when its supposed to lie and when its not supposed to? Are you going to have to manually alter that time server twice a year now too?

I think my 7th grade programming class we worked on calculating timezones and DST.. you got exactly what you paid for when you got a $150 PTZ.. $149 worth of hardware, and $1 worth of software.

how many of these did you buy that changing DST twice a year is more work than writing your own software to bust NTP Specs?
Click to expand...
You are over complicating it...all the user would have to do is disable dst on all the cameras. Done. Never have to set it again. DST changes at 1/2am, this will keep the time stamp accurate. Much more elegant than going into each camera and setting dst....
 
The thing about network time servers are they are network syncing, if you offset the time it can no longer sync with other NTP Servers.. you can do it right now, just change your system time by an hour and dont let it ever update from the internet.. of course you can never get time from an upstream NTP server again, because that well requires them all to sync on GMT

and now your left to manually altering time twice a year on your NTP Server and loosing ability for your Timeserver to sync upstream, all so you dont have to buy cameras that can handle this all on its own like they are supposed to.. all my cameras have correct time and i didnt do anything to em this weekend, thats keeping it simple.. you guys are over-complicating things.
 
You must log in or register to reply here.
Top Bottom