Repository navigation
Conversation
A single offset captured at scheduling time was applied to future local times, so an occurrence spanning a daylight saving transition drifted by an hour in both its predicted datapoints and its replay.
|
wborn
left a comment
wborn
left a comment
There was a problem hiding this comment.
This is an initial AI-assisted review.
The PR addresses the timezone handling issue for single occurrences and adds useful test coverage for daylight saving transitions. However, converting replay offsets to local wall-clock times can cause distinct predicted datapoints to receive the same timestamp during a spring-forward transition. This edge case should be addressed, with a regression test, before merging.
| return predictedDatapoints; | ||
| } | ||
| long UTCTimestamp = timestamp - tzOffset; | ||
| long UTCTimestamp = toEpochMillis(timestamp, timezone, nowUTC); |
There was a problem hiding this comment.
Converting replay offsets to local timestamps can produce duplicate predicted datapoints during a DST gap.
For example, with an occurrence starting at midnight on March 29, 2026 in Europe/Amsterdam, offsets of 7,200 and 10,800 seconds both resolve to 03:00 CEST. Previously, these offsets produced distinct predicted timestamps.
Could this case be handled explicitly, and could a regression test cover datapoints spanning a spring-forward transition?
This branch has not been deployed
2 participants
Description
Checklist