test(ohlcv): seed the cache mtime in local time so the cache tests pass outside UTC

[codify88]

What's wrong

Eight tests in tests/test_ohlcv_latest_bar.py and
tests/test_ohlcv_cache_freshness.py fail on any machine whose local timezone is
behind UTC. They pass in CI, which runs ubuntu-latest in UTC.

The fixtures seed a cache file's mtime through pandas:

os.utime(cache_file, (today.timestamp(), today.timestamp()))

pd.Timestamp.timestamp() reads a naive Timestamp as UTC. But
_cache_is_fresh reads the same mtime back with
pd.Timestamp.fromtimestamp(), which returns local time:

written = pd.Timestamp.fromtimestamp(os.path.getmtime(data_file))
if written.date() != now.date():
    return False

The round trip loses the UTC offset. On America/New_York:

seeded mtime : 2026-05-08 00:00:00  -> epoch 1778198400.0
read back as : 2026-05-07 20:00:00
dates equal? : False   <- _cache_is_fresh rejects the file

So load_ohlcv treats a file it was just handed as written yesterday, refetches,
and trips the fixtures' _fail_download guard — surfacing as
AssertionError: should use the seeded cache, not download and
AssertionError: fresh cache must not refetch.

Why this is worth taking

It is a test-only fix. load_ohlcv is already self-consistent: both now
(pd.Timestamp.today()) and written (fromtimestamp) are local. No production
behaviour changes, and the freshness rule from #1150 is untouched. The fixtures
were the only thing straddling two time frames.

It removes a false failure that only contributors see. Because CI is UTC, the
suite is green on every PR while being red for any contributor in the Americas
who runs pytest locally. That asymmetry is expensive in a way that does not
show up in CI: eight red tests on a first checkout look like a broken repo or a
broken change, and the natural response is to go hunting in stockstats_utils.py
— which is correct — or to stop trusting the local suite. Both cost maintainer
time in triage.

It protects a guard that is meant to be strict. These tests exist to prove
load_ohlcv does not hit the network when a same-day cache is present. Right
now, for a large fraction of contributors, they fail for a reason unrelated to
that property, so a genuine regression in the caching path would be
indistinguishable from the usual local noise.

The fix

Seed the mtime through datetime.timestamp(), which reads a naive datetime as
local, so both sides of the comparison are in the same frame. Four call sites, a
comment at each explaining the trap.

Verification

pytest -q on the full suite, and the two affected files across the range:

TZ	Result
UTC	19 passed
America/New_York (UTC-4)	19 passed
America/Los_Angeles (UTC-7)	19 passed
Pacific/Midway (UTC-11)	19 passed
Pacific/Kiritimati (UTC+14)	19 passed

Before the change, all five non-UTC zones fail 8 of those 19.

Reproduced on 2d17df8 (v0.5.0).

🤖 Generated with Claude Code

[Yijia-Xiao]

Thanks @codify88. Fixed in 2340fe4 (#1372).