Fix CHRONOLOGICAL_ORDER to reject camera clock-reset EXIF dates

A real album (irregular.ninja/so.war.das) surfaced the bug: a Fujifilm
X100V whose battery died reset its clock to 2000-01-01, and every EXIF
timestamp on that roll was stamped with the bogus date instead of being
omitted. Trusting it at face value sorted that whole roll to the front
of the album, ahead of hundreds of correctly-dated 2020s photos.

EXIF years before 2001 are now treated the same as a missing date tag.
The no-date fallback also switches from source mtime to filename order,
since mtime is not reliable either -- bulk-copying/rsyncing an incoming
directory commonly rewrites every file's mtime to the transfer time,
unrelated to capture order -- while sequential camera filenames track
real shooting order even across a clock reset.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

1 files changed, 4 insertions, 3 deletions

diff --git a/README.md b/README.md
index c8c71b6..d12c0ee 100644
--- a/README.md
+++ b/README.md
@@ -123,9 +123,10 @@ Feature toggles at a glance:
   repeatable.
 * **Chronological order** (`CHRONOLOGICAL_ORDER=no`, the default): set to
   `yes` (or pass `--chronological`) to order the main album's photos by EXIF
-  date taken instead of filename/shuffle order, falling back to source mtime
-  for photos with no usable EXIF date. Takes precedence over `SHUFFLE` when
-  both are enabled.
+  date taken instead of filename/shuffle order (years before 2001 are
+  treated as an implausible camera clock-reset default, not a real date),
+  falling back to filename order for photos with no usable EXIF date. Takes
+  precedence over `SHUFFLE` when both are enabled.
 
 ## Documentation