What the Photo Time-Zone Estimator does
A photo carries up to three clocks and they do not have to agree. This tool lines them up: the camera's local capture time, the UTC offset the camera claimed, and the satellite timestamp in the GPS block, which is always UTC. The difference between the first and the last is the offset the photo was really taken at, and the gap between that and the offset tag is your camera clock error, in minutes.
It is the check to run before sorting a trip's photos, merging two cameras into one timeline, or arguing about when something happened. Everything is read in your browser; no file is uploaded and no time-zone service is contacted.
How to use it
- Drop in the photos you want to check - one is enough to spot a wrong clock, a set is better for finding two cameras that disagree.
- Read the summary line: how many photos agree with their own offset tag, how many contradict it, and how many carry no offset tag at all.
- Work through the table. Each row shows the local capture time, the offset tag, the GPS UTC time, the offset those two imply, the clock error in minutes and the local time the photo would carry if the clock were corrected.
- Use the corrected time when renaming or re-dating files. It is the local capture time shifted by the measured error, so the photograph keeps the moment it was actually taken.
- Export the table as CSV if you are going to fix the files in another tool, or JSON if you are scripting it.
Reading the results
The implied offset is arithmetic, not a guess: local capture time minus GPS UTC time, rounded to the nearest quarter hour for display, with the raw difference shown when it is not an exact quarter.
A clock error of a minute or two is normal drift and nothing to act on. An error of an exact number of hours is a camera left on the previous country's time; an error of exactly one hour is usually a summer-time change the camera did not know about.
"By longitude" is the offset the sun keeps at that longitude - longitude divided by 15 - and it is an indication of where in the world the photo sits, nothing more. Political zones follow borders: the whole of China runs on UTC+08:00, India on UTC+05:30, and Spain sits an hour ahead of its meridian.
Where there is no GPS timestamp, there is no independent clock in the file and no error can be measured. The page says so rather than inventing a zone from the coordinates.
Worked example: a camera still on Indian time in Kyoto
The file records DateTimeOriginal 2025-04-02 08:15:00 and OffsetTimeOriginal +09:00, which together claim the photo was taken at a quarter past eight in Japan. The GPS block records 2025-04-02 02:45:00 UTC.
Local minus UTC is 5 hours 30 minutes, so the implied offset is UTC+05:30 - India, not Japan. The offset tag says +09:00, so the clock error is 330 minus 540, which is -210 minutes: the camera is three and a half hours behind local Japanese time.
The corrected local time is 08:15:00 plus 3 h 30, which is 11:45:00 - late morning in Kyoto, which matches the light in the photograph. The longitude of 135.785 degrees gives a solar offset of UTC+09:00, agreeing with where the photo was taken and disagreeing with the camera, which is exactly the pattern a clock left on the wrong country's time produces.
Why the GPS timestamp is the one to trust
A camera's internal clock is set by hand, runs on a small battery and drifts. The GPS timestamp comes from the satellite signal itself, which is how satellite navigation works at all: the receiver cannot produce a position without an accurate time. If a file carries a GPS timestamp, that timestamp is as good as any clock you own.
This is why the tool measures the offset rather than looking it up. Working out a time zone from coordinates needs a zone boundary database and still gets summer time wrong at the edges; subtracting two timestamps the file already contains gets the actual offset, for that photo, on that day, with no database at all.
Limitations: what the result does not prove
- Without a GPS timestamp there is nothing to compare the camera clock against, so no error can be measured and none is claimed.
- The implied offset is not an IANA time zone. It tells you the photo was taken at UTC+05:30; it cannot tell you whether that was Kolkata or Colombo, and it says nothing about what the zone does in another month.
- The longitude figure is a rough indication of position, not a zone. Large countries run one zone across many meridians, and several run offsets that no solar calculation would produce.
- Some cameras write the GPS timestamp only when a fresh fix is available, so an occasional row will have a GPS time minutes away from the capture time. Treat a stray few minutes as a stale fix rather than a clock fault.
Privacy: where your data goes
Everything you paste, type or drop is processed in this browser tab. It is not uploaded, logged, stored or sent to analytics. Session recording and tag-manager scripts are switched off on this page.
Standards and sources
- CIPA DC-008 Exif 2.32 specification - checked 19 Sep 2026
- IANA Time Zone Database - checked 19 Sep 2026
- US Coast Guard Navigation Center - GPS timing
Frequently asked questions
What is the OffsetTimeOriginal tag?
It is the Exif tag that records the UTC offset the camera believed it was in when the photo was taken, written as +05:30 or -08:00. It was added in Exif 2.31 in 2016, so older cameras never write it and a good many newer ones still do not. Without it, a capture time is a bare local time with no zone attached.
How do I know if my camera clock is wrong?
Compare the local capture time with the GPS timestamp in the same file. The difference is the offset the photo was taken at; if it does not match the offset your camera recorded, or the offset of the country you were in, the clock is wrong by the difference. This tool does that subtraction for every photo you give it.
Can you work out the time zone from the coordinates?
Not reliably, and this page does not pretend to. Mapping a coordinate to a zone needs a boundary database, and even then the offset depends on the date because of summer time. What the coordinates do give is a sanity check: the solar offset from the longitude, shown as an indication only.
Why do two cameras at the same event have different times?
Because each clock was set separately and each has drifted since. Run both sets through here, read the clock error for each camera, and shift one set by the difference before merging them. The GPS timestamp, where present, gives you the true offset for each body.
Does a phone photo always have the right time?
Usually, because phones set their clock from the network and update the offset when they cross a border - but not always. Aeroplane mode, a phone that never found a network, or a camera app writing the offset at import rather than at capture can all leave the wrong value in the file.
What should I do about a photo with no GPS time and no offset tag?
Treat its timestamp as a bare local reading with an unknown zone. If you know where it was taken and on what date, you can apply the offset yourself; if you do not, the file genuinely does not say, and any zone assigned to it is an assumption that ought to be recorded as one.
Will changing the capture time also change the GPS timestamp?
No, and it should not. The GPS timestamp is the satellite record of when the fix happened; only the camera's local fields need correcting. Keeping the original UTC timestamp is what lets anyone check the correction later.
Last reviewed by the A2Z.Tools team against the sources listed above.
