Changing Time Zone on multiple cameras through network

[CTO]

Hey there,
I'm the sysadmin of a yacht. We've got a Milestone Server set up with 20 cameras. These cameras are network time synced with our domain on board.

Being a yacht, we're often travelling in and out of different time zones. Does anyone know of any way to change the time zones on the cameras / clients centrally, rather than going one by one through each camera and changing it through the gui? Not sure if this fell under a network question, or a Milestone server question.

The cameras, Milestone clients and milestone server all get the NTP from our Windows domain server. I'm searching everywhere for an ability to change time zones on one PC and have it reflect to everything on the security network but haven't come across anything.

 

[Flintstone61]

Not sure if this will work for your situation, but it was recommended to me by other forum users.
Although I don't see where it is aware of itself traveling across timezones. I think there must be a marine device to keep ships on local time....

 

[SpacemanSpiff]

Have you tried updating the time on the domain server (DS) as you change zones? As you already shared, the DS is also the NTP for milestone server/clients

 

[Flintstone61]

 

[bp2008]

NTP doesn't communicate time zone info as far as I know, so you'd need to change the time zones of the cameras via their API (should help if the cameras are all the same brand). You might be able to find a batch configuration tool from the manufacturer or an open source one on github, or as a last resort you could write your own fairly simple script to do the change (a GPT4 chatbot such as Bing chat could probably help a lot with this if you aren't good at programming).

I would be hesitant to frequently change the time zone of systems like this however. It could get confusing and possibly create file naming conflicts and other bugs because software is frequently engineered to use "local time" in timestamps, database records, etc. Issues crop up often enough just with daylight savings in many parts of the world when one hour gets repeated once a year. It may be best to just set the cameras/NVR/etc to UTC or another common time zone of your choice and leave the settings alone. Maybe put a "current timezone offset" label somewhere in your system. Like if it was a Blue Iris system, I would put something like "UTC +4" into a macro text file and overlay that on every camera's video stream, and then people accessing the system could see the label and know to add 4 hours to the timestamps to get their current local time. When the ship moved to a different time zone I could just update that one text file and it would update all the text overlays on the cameras.

 

[bp2008]

If the camera system (including NVR) has no internet connectivity, then you could technically just edit the system time to make all the timestamps appear correct, install an NTP server on the Milestone server, and let it be the time source for the cameras or for other clients. Not a perfect solution though; you still get to deal with all the potential software bugs caused by repeating the same hours of time over again, and if you tried this on a system with internet access you could have problems with TLS certificate validation and some other protocols due to the clocks being out of sync with the rest of the world. You also wouldn't be able to use the Windows domain from a machine that is more than a few minutes out of sync with the domain server.

 

[CTO]

Thanks for the responses guys.

Have you tried updating the time on the domain server (DS) as you change zones? As you already shared, the DS is also the NTP for milestone server/clients

Yeah, it doesn't change any of the cameras or client workstations to the updated time zone. That's kind of the route I was wanting to go down. Just to change everything from there.

NTP doesn't communicate time zone info as far as I know, so you'd need to change the time zones of the cameras via their API (should help if the cameras are all the same brand). You might be able to find a batch configuration tool from the manufacturer or an open source one on github, or as a last resort you could write your own fairly simple script to do the change (a GPT4 chatbot such as Bing chat could probably help a lot with this if you aren't good at programming).

I would be hesitant to frequently change the time zone of systems like this however. It could get confusing and possibly create file naming conflicts and other bugs because software is frequently engineered to use "local time" in timestamps, database records, etc. Issues crop up often enough just with daylight savings in many parts of the world when one hour gets repeated once a year. It may be best to just set the cameras/NVR/etc to UTC or another common time zone of your choice and leave the settings alone. Maybe put a "current timezone offset" label somewhere in your system. Like if it was a Blue Iris system, I would put something like "UTC +4" into a macro text file and overlay that on every camera's video stream, and then people accessing the system could see the label and know to add 4 hours to the timestamps to get their current local time. When the ship moved to a different time zone I could just update that one text file and it would update all the text overlays on the cameras.

The little text on screen would be a winner actually. I didn't know about that feature in the Axis cameras so I tried playing around. It would be nice if there was a %UTC + Local Offset text. However it's something I can read more about. I'll look into the API too. We have a mix of Axis and Panasonic cameras on board.

I take on board (pardon the pun) what everyone is saying about changing time zones frequently. I'll need to see what everyone would be happy with on board. From a user experience, it does look a lot better when the cameras, and clients are showing the local time for searching an event.

 

[roymickton]

Can't you just point your cameras NTP to the central NTP server? Not sure what hardware you are running but on my setup I have a port forward rule pointing all the clients to intercept and redirect any NTP requests (even if the client has a hard-coded NTP it will be re-directed to my central NTP).