{
  "status": "Illustrative acceptance plan, not an executable test suite or observed production result",
  "topic": "Fitness app timezone bugs",
  "date": "2026-11-04",
  "sourceArticle": "https://aptixlabs.com/insights/fitness-app-timezone-data",
  "setup": [
    "Use synthetic accounts and records",
    "Record the environment and implementation version",
    "Agree the expected product contract before testing"
  ],
  "reviewSequence": [
    "Define day-assignment rules for each metric",
    "Preserve event identity and timezone context",
    "Build midnight travel and daylight-saving fixtures"
  ],
  "cases": [
    {
      "id": "1",
      "condition": "A session crosses midnight",
      "expectedBehavior": "One documented day-assignment policy applies",
      "observedBehavior": null,
      "status": "not_run"
    },
    {
      "id": "2",
      "condition": "A local hour repeats",
      "expectedBehavior": "Distinct instants remain distinguishable",
      "observedBehavior": null,
      "status": "not_run"
    },
    {
      "id": "3",
      "condition": "User changes reporting timezone",
      "expectedBehavior": "Historical presentation follows the chosen policy",
      "observedBehavior": null,
      "status": "not_run"
    }
  ],
  "tradeoff": "Rebucketing historical data after every timezone change can make prior reports appear inconsistent. A clearly documented reporting timezone is often easier to explain than silent recalculation."
}