Camera clock offsets need an explicit anchor
Choose a correction sign, keep unrelated dates and avoid implying timezone repair.
A camera clock error is a batch assumption
The reviewed photo-author discussion asks how to change wrong Exif creation dates. The accepted answer uses a fixed clock offset, and later comments describe aligning batches from multiple cameras. That supports this complete correction task without proving a browser preference or market volume.
One offset fits photos made while one camera had the same clock error. A changed clock setting or a second camera may require another batch. An anchor is evidence you provide: it is not a timezone inferred from pixels or a filename.
Keep the sign and date priority explicit
Exact integer seconds and recorded/actual anchors are mutually exclusive. Anchors use YYYY:MM:DD HH:mm:ss and change every selected existing field by the same wall-clock offset. No timezone inference or missing-tag creation.
Only DateTime, DateTimeOriginal and DateTimeDigitized can be selected. XMP dates, OffsetTime, SubSec, GPS, compressed pixels and every other byte stay unchanged. File-system dates are not edited.
| Known situation | Explicit input | Remaining check |
|---|---|---|
| Camera 2 minutes ahead | -120 | All corrected dates remain valid |
| Recorded 12:02, actual 12:00 | Two same-date anchor values | Anchor is representative of this batch |
| Organizer shows unchanged XMP date | Only selected Exif fields change | Inspect organizer date priority |
A complete audit is separate from a short preview
The screen previews at most 20 changed fields and copies a bounded batch summary. The ZIP contains every corrected JPEG, complete clock-report.json, formula-safe clock-changes.csv and copy.txt. Source names, indices, hashes and selected/unselected dates remain complete.
The complete source identity, unselected dates and byte offsets remain in JSON even when only 20 changed fields are shown on screen. The corrected copies retain compressed image bytes and unrelated metadata. Keep originals independently; the download is a correction package rather than an archive of original JPEG files.
- Check the offset sign with one known moment before processing the batch.
- Review every source and selected/unselected field in clock-report.json.
- Keep originals and compare receiving-program dates before adopting the corrected copies.
An explicit refusal preserves the whole-batch promise
Baseline 8-bit SOF0, one interleaved scan and terminal EOI; exactly one classic little- or big-endian Exif TIFF. Progressive JPEG, BigTIFF, multiple Exif sections, MPF, JUMBF, trailers and unsupported structures refuse the entire queue.
Malformed, unsupported, missing-field, over-budget, cancelled or timed-out input yields no partial package. The whole operation has a 10-second deadline, including local loading and file reads; retry the same selected originals after cancellation.
A cancellation or deadline ends unfinished work without returning a partial success. Rerunning the same selected original Files starts fresh; the browser does not upload them or detach their original content.
References
- Photo authors — correcting wrong camera timestamps
Complete first-person question, eleven answers and fourteen answer comments reviewed for admission. The accepted clock-offset approach and multi-camera feedback support this task; original files, browser preference, region and demand volume remain unknown.
Tools in this category
Expand a tool to see its steps, options and supported formats, then open its workspace.
Correct photo capture clocksApply one explicit clock correction to existing JPEG Exif dates; keep every other source byte and download the full change report.
A camera clock was wrong across a photo batch. Add exact seconds, or give one recorded and actual wall-clock pair, then choose the existing date fields to change. Keep originals and compare every corrected copy with the complete report.
Steps
- Choose all supported original JPEG photos with the same camera-clock error.
- Enter exact seconds or one recorded/actual anchor pair; select existing date fields.
- Run, compare before/after preview rows and the batch summary, then download the complete ZIP.
- Use clock-report.json and corrected copies to review every source, field, byte span and hash; check the receiving program’s date priority.
Available options
- Correction method
- Exact seconds to add · Recorded and actual clock pair
- Exact seconds to add
- 0
Positive adds time; negative subtracts time. Whole seconds only, from −315537897599 to +315537897599; every corrected year must remain 0001–9999.
- Recorded wall-clock time
- Enter as needed
- Actual wall-clock time
- Enter as needed
- Existing date fields to change
- Capture time — DateTimeOriginal · Digitized time — DateTimeDigitized · Image change time — DateTime
Select at least one. Every photo must contain every selected field; otherwise the entire queue refuses.
Capabilities and limits
- 1–500 original JPEG Files, 10 MiB each and 100 MiB total; filenames up to 512 UTF-8 bytes. The picker may impose a shorter basename limit.
- Baseline 8-bit SOF0, one interleaved scan and terminal EOI; exactly one classic little- or big-endian Exif TIFF. Progressive JPEG, BigTIFF, multiple Exif sections, MPF, JUMBF, trailers and unsupported structures refuse the entire queue.
- Per photo: 4096 markers, 5 supported IFD roles, 512 entries per IFD and 1500 entries; queue total 100000 entries. Selected date values must be existing 20-byte ASCII fields with valid years 0001–9999.
- Exact integer seconds and recorded/actual anchors are mutually exclusive. Anchors use YYYY:MM:DD HH:mm:ss and change every selected existing field by the same wall-clock offset. No timezone inference or missing-tag creation.
- Only DateTime, DateTimeOriginal and DateTimeDigitized can be selected. XMP dates, OffsetTime, SubSec, GPS, compressed pixels and every other byte stay unchanged. File-system dates are not edited.
- The screen previews at most 20 changed fields and copies a bounded batch summary. The ZIP contains every corrected JPEG, complete clock-report.json, formula-safe clock-changes.csv and copy.txt. Source names, indices, hashes and selected/unselected dates remain complete.
- Malformed, unsupported, missing-field, over-budget, cancelled or timed-out input yields no partial package. The whole operation has a 10-second deadline, including local loading and file reads; retry the same selected originals after cancellation.
- Report and CSV each have an 8 MiB guard; complete binary plus text and binary plus metadata each have a 128 MiB guard. Processing stays in this browser, without uploading names or contents. Source pixels are not decoded or re-encoded by this tool.