Satellite Time versus True Time ? 7DMkII

Ever since the last time change, November I think, I have had my 7DMkII set such that the clock is automatically updated by the GPS satellite thingie.
As best I can tell, the clock display and the time-stamp are dead on the money with computer time.

I have just now found a field in my EXIF, "GPS TimeStamp"; and, I am a bit surprised to find that this time display is 17 seconds faster than the timestamp on the images.
I looked at several images and the GPS Timestamp is consistently 17 seconds faster than the timestamp that displays as Date Taken.

I would have assumed the two would be in perfect agreement; in fact, I would have thought it would not be possible for them not to be in agreement.

Your thoughts and ideas please.

Probably the way the software is working under the covers with granularity to minutes vs seconds. Not all date/time utilities work the same, and it is very possible the software at some point only deals down to the minute, and then somehow a 17 sec offset gets added to complete the timestamp values. I have seen stranger things come out of our own software.

GPS time and UTC are not the same. The GPS time runs coninuously, with 60 seconds each minute and 60 miuntes each hour and so on.
UTC (Universal Time Coordinated) is the base for the time used in all time zones. UTC itself is the same as GMT (Greenwich Mean Time). But UTC supports leap seconds. Last time I checked, there was a difference of 18 seconds between GPS and UTC. The signal sent out by the satellites contains GPS time, but also information about the difference between GPS time and UTC. What you saw was probably based on GPS time, since the difference is in that range you indicate.

That may be it and because the camera would be calculating UTC from GPS time, it would have to subtract a hardcoded value like GPS receivers do now.

Today that delta is 19 seconds, it was 18 seconds back in 2017, but the 7d2 came out before that even, so likely when the software was developed for the camera, that delta was 17 seconds.

No, these values should not be hardcoded. The Delta is sent together with information from the satellite. If they did indeed hardcode that, then they made a mistake.

Many GPS receivers hardcode the offset at time of firmware development.

https://timetoolsltd.c​om/gps/what-is-gps-time/

Obviously the 7d2 is doing this because today that offset is 19 seconds.

Can there really be that many idiots developing software for GPS receivers?

From the page you linked to: In order to be more useful for timing applications, GPS messages contain an offset between GPS and UTC time which allows current UTC time to be calculated by a low-cost ground based receiver.

Depends on those that write requirements…. If requirements say “gps time has to be offset by leap seconds, currently 17”, then yes a programmer will likely translate that to be a hardcoded value.

If requirements say “the frame of gps data that contains time also contains leap seconds, use that to determine utc”, then you get a different implementation.

The “laziness” of a programmer is inversely proportional to the amount of time left before a deadline.

UTC was adjusted in 2012 (16) I believe, and then again in 2015 (17). The 7D2 came out between this time. So either at that time, the offset was coded as 16 seconds (would have to go back to raw files from its release to see), and then subsequent firmware updates changed that to 17, or they were "future proofing" during the original firmware of the camera/GPS receiver and went for 17 to be safe despite it being 16 at the time.

However I am sure there were 7D2 firmware updates past 2016 even but maybe not? If there were, nobody bothered to adjust the offset to 18.

Leap Second Insertion Date TAI-UTC GPS-UTC Offset
December 31, 2016 37 seconds 18 seconds
June 30, 2015 36 seconds 17 seconds
June 30, 2012 35 seconds 16 seconds
December 31, 2008 34 seconds 15 seconds

There are online calculators that determine the offset. One, at https://www.labsat.co.​uk …hp/en/gps-time-calculator, calculates the offset as of 8 AM today as 18 seconds (see attached image). But if I change the year to 2027, 5 years hence, the offset is still 18 seconds. GPS time does not adjust for leap seconds, it is ahead of UTC(USNO) by the integer number of leap seconds that have occurred since January 6, 1980 plus or minus a small number of nanoseconds.

When is the next leap second? Maybe in December 2022. You read about it at https://www.timeanddat​e.com …20December%2031​%2C%202022.

UTC is adjusted from time to time, and isn't constant. So that calculator has no idea when they will make the next adjustment, thus why it doesn't change for the future, it cannot predict when they (whomever they are) will adjust UTC again. It is due for an update soon since we are really at 19 seconds or very close to it.

The issue here is though that EXIF shows 2 timestamps: GPS time and time image was taken, but due to Canon hardcoding the leap second offset, that image timestamp is off by 1 second compared to UTC and soon to be off by 2 seconds. Canon could have taken the GPS data and used it, but it certainly appears they just hardwired 17 seconds into their code.

Mystery solved by Anders!

apersson850 wrote in post #19359525
Can there really be that many idiots developing software for GPS receivers?

From the page you linked to: In order to be more useful for timing applications, GPS messages contain an offset between GPS and UTC time which allows current UTC time to be calculated by a low-cost ground based receiver.

Sigh. Not just for GPS receivers.

I see apps and programs, and web sites with:

• "buttons" that look like text in boxes
  
• Controls that don't give feedback they have been activated so one presses them multiple times because the response is slow
  
• Programmers that don't use the appropriate keyboard for data entry (both iOS and Android have keyboards specific for entering phone numbers, e-mail addresses, etc thay reduce errors and make it easier for the user)
  
• No attempt at data validation
  

TeamSpeed wrote in post #19359526
Depends on those that write requirements….

That's the same thing. They are involved in the development cycle.

apersson850 wrote in post #19359963
That's the same thing. They are involved in the development cycle.

BA are not coders at all, and in today’s agile environments, the ones writing up change stories may be very non technical. Product owners don’t have to understand anything about development these days.

I am on two scrum teams now and have watched BA individuals and business users both create requirements, and it falls on the dev team to refine the development rules. I have been on many waterfall projects too, and back in the day BA members were indeed more technical, but in many environments now, that isn’t true.

Just because they make up a software development life cycle, sometimes it has nothing to do with developers being lazy or not, it has to do with how requirements are written, and subsequently refined to software design. Garbage in usually equates to garbage out, not always but many times.

I sure did not know what an interesting can of worms I had opened with my question.

I was never before aware that we had leap seconds and the like.

TeamSpeed wrote in post #19360016
BA are not coders at all, and in today’s agile environments, the ones writing up change stories may be very non technical. Product owners don’t have to understand anything about development these days.

I am on two scrum teams now and have watched BA individuals and business users both create requirements, and it falls on the dev team to refine the development rules. I have been on many waterfall projects too, and back in the day BA members were indeed more technical, but in many environments now, that isn’t true.

Just because they make up a software development life cycle, sometimes it has nothing to do with developers being lazy or not, it has to do with how requirements are written, and subsequently refined to software design. Garbage in usually equates to garbage out, not always but many times.

You are countering yourself.
Either the product owner doesn't know, so he hires somebody who should know and do the development right.
Or the product owner does know very well, in which case he should issue relevant specifications.
"Development" isn't just the coding part. It's the whole process.