A midnight boundary splits one evening across two files at exactly the moment
the session is most worth reading whole: the 01:30 crash lands in a different
file from the 23:00 run that set it up. And a 02:00 session is "last night" to
everyone who was in it, so filing it under the new calendar date reads wrong
even when nothing goes bad.
So shift the clock back 6h before taking the date for the FILENAME. The log day
runs 06:00 -> 06:00 and one night stays in one file.
Only the filename moves. The session header and the lastrun breadcrumb each
call GetLocalTime separately (three distinct SYSTEMTIMEs in this function), so
every timestamp a human reads is still true local time -- checked the scoping
rather than assuming it, since sharing one variable would have silently
backdated the header by six hours.
FileTimeToSystemTime carries the month and year boundaries, verified against a
scratch harness rather than reasoned about:
2026-07-28 20:00 -> solo_20260728.log one playtest night,
2026-07-28 23:59 -> solo_20260728.log start to finish,
2026-07-29 00:01 -> solo_20260728.log in a single file
2026-07-29 05:59 -> solo_20260728.log
2026-07-29 06:00 -> solo_20260729.log the boundary
2026-08-01 01:00 -> solo_20260731.log month
2027-01-01 03:00 -> solo_20261231.log year
2026-03-01 02:00 -> solo_20260228.log non-leap February
Nothing in the tooling parses these filenames -- the operator app's own log is
operator_relay.log and _collect_egg is mission settings, not logs -- so the
console auto-transfer is unaffected.
The player-facing text did need fixing though: the bats and README told players
to send the log "dated today", which is now wrong for anyone who plays past
midnight. They now say to take the NEWEST one and ignore the date, with a note
on why. That was already the safer instruction.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
