Zulu Time

Timezones!

An NVR in New York  is recording one camera in Nevada and one in Maryland. We just left Daylight Savings time, and the video is being watched by an investigator in an office in Arizona.

Phew…

The first thing we realize is that the location of the NVR really doesn’t matter, it is the location of the camera which is interesting. An NVR must know where the cameras are – geographically.

Second problem is that the term “2.40” am is ambiguous when we leave daylight savings time. “Let’s meet at 2.40 am”, “what 2.40? the first time, or the second?”

Third is that the investigator needs to be aware where the cameras are. “We had a burglary at 6 p.m.” is also ambiguous unless we know where it was 6 p.m.

Military solution

For the ones who’s been in the army,  the term “zulu time” might be recognized. No DST, no timezones, no ambiguity, but not exactly user friendly 🙂  In the programming world we have some options too – Microsoft has a concept of “FILETIME” which is 100-nano second intervals since January 1, 1601, another common solution is seconds since January 1, 1970, and of course  there are a couple of other options, but the principle is that you simply count the number of time units since a fixed point in time. Most, if not all, solutions use Greenwich as the reference location.

We then present the time differently, depending on the location of the operator. By letting the operator specify their location (usually via a control panel in the OS), we know how to convert from “seconds since epoch at Greenwich” to regular looking date and time in Arizona. Naturally, the OS needs to know what timezone AZ is in, and that AZ do not observe DST (good for them!).

By the same token, when an operator enters a time, we need to know what location the operator is referring to when they say “go to 4 pm, april 1st, 2010”. Unless we know where, we cannot make the inverse computation and get back to seconds since epoch.

There are basically 3 possibilities;

  1. The operator uses their own local time
  2. The operator uses the NVRs local time
  3. The operator uses the cameras local time

Is this a real problem?

In lots and lots of cases, the operator, the NVR and the cameras are in the same timezone, so there is no ambiguity, but what happens when they are not? In a large corporate environment, a central NVR cluster might record from offices all over the world. It is not difficult to imagine the annoyance that it would be when someone asks you to find an incident in Hong Kong, at 3 pm local time. You find the camera in Hong Kong, and now the puzzle starts. Well – I am in New Jersey, so do I enter 3 pm (Hong Kong time), so I enter Hamburg Germany time (location of the NVR) or do I calculate the 3 pm Hong Kong time into New Jersey time and enter that?

Most cameras allow you to overlay the local time on the frame, so that solves part of the puzzle. The operator immediately realizes the difference between what they enter, and what they see on the screen, but when they don’t – well – then it all gets a little confusing.

Advertisements
Tagged , ,

2 thoughts on “Zulu Time

  1. I agree that time zones can be an interesting and challenging aspect.

    However, investigators do not usually need to search across time zones. I don’t see the use case for it as more searches are inherently physical (e.g., show me what happened overnight in the Warsaw warehouse, etc.). I am sure there are some edge cases where someone wants to search for alarms overnight at all locations around the world but these seem rarer.

  2. prescienta says:

    Absolutely, and from a technical perspective it can be challenging to get absolutely right. I think this could be one of the borderline instances where an attempt to make it user-friendly, might actually end up causing more confusion than it removes.

    When you are working on an incident I would suspect that you are watching cameras that are geographically close – most likely in the same building or campus, in that case, regardless of the strategy pursues, the offset between entered time and shown time would be a constant. If the “camera time” is displayed there will not be any ambiguity either.

    Although, I wonder if people WOULD be confused if they bring up 2 cameras from different time zones (not very useful perhaps, but people will probably try at least once), then they would have two different local times (embedded in the frame), and possibly a third (the NVR recording time, which is usually overlaid).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: