Aglet

Verify scheduled runs before and after a timezone transition

Verification should prove that the schedule honors its stated local rule across ordinary and offset-transition dates. Use independent expected values and read the persisted occurrence after scheduling. Compare due and start times separately so worker delay does not look like timezone conversion drift.

Check whether the outcome improved

  1. Verify an ordinary date

    Create a recurrence on a date without the reported calendar boundary. Confirm the stored timezone, displayed local time, calculated UTC due value, occurrence ID, and actual start align. Preserve the result as a control for the boundary fixtures.

  2. Verify the boundary before and after

    Run paired occurrences on both sides of the transition or rule boundary. Check local dates, UTC instants, next-occurrence values, and actual starts. Confirm no occurrence is duplicated or omitted and record any documented ambiguous local-time behavior explicitly.

  3. Verify the reader’s next-run view

    Read the schedule from a fresh session and compare its displayed next local time with persisted due data. Introduce a known worker delay to ensure the view still represents due time, not start time. Reconcile all run IDs after the interval ends.

What to carry forward

Accept when ordinary and boundary occurrences preserve the documented local rule, UTC due values, occurrence identity, and start behavior. Keep worker delay distinct from conversion. Reopen verification if the stored zone is lost, a local boundary duplicates a run, or the next-run display disagrees with persisted scheduling data.

Technical background: Rails guides.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow