test(dataflows): stamp cache mtimes in the zone the freshness check r…

[shivsin25]

Fixes #1372

Cause: the OHLCV cache tests stamped a file's mtime with pd.Timestamp.timestamp(), which reads a naive value as UTC, while _cache_is_fresh reads it back with pd.Timestamp.fromtimestamp(), which returns local time. The two conventions disagreed by the machine's UTC offset -- far larger than the 900s TTL in most zones -- so whether a case passed depended on where it ran. Positive offsets made the file look newer than it was (3 failures); negative offsets made it look older, tripping a different set.

Production is unaffected: it compares a local now from pd.Timestamp.today() against a local written, so both sides shift together. This is test-only, as the report says.

Fix: stamp via datetime.timestamp(), which reads a naive value as local and is therefore the exact inverse of pd.Timestamp.fromtimestamp. The conversion lives in one helper in conftest so the four call sites across the two files cannot drift, and a round-trip test pins the requirement directly rather than leaving it implicit in every os.utime call.

Verified on Asia/Kolkata (UTC+5:30), where 3 of the 19 cases failed before and all pass after. Modelling the conversion across zones shows the skew was exactly the UTC offset before and is zero after:

timezone              before        after
UTC                       +0s          +0s
Europe/London          -3600s          +0s
Asia/Tokyo            -32400s          +0s
Asia/Kolkata          -19800s          +0s
America/New_York      +14400s          +0s
America/Los_Angeles   +25200s          +0s

[Yijia-Xiao]

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