Merge pull request #419 from wordpress-mobile/fix-milestone-dst-bug

Fix milestone due date bug when crossing DST boundaries

Author: AliSoftware

CHANGELOG.md

@@ -15,6 +15,7 @@ _None_
 ### Bug Fixes
 
  - Improve resilience of the `ios_lint_localizations` action to support UTF16 files, and to warn and skip files in XML format when trying to detect duplicate keys on `.strings` files. [#418]
+ - Work around GitHub API bug when creating a new milestone, where their interpretation of the milestone's due date sent during API call is incorrect when we cross DST change dates — leading to milestones created after Oct 30 having due dates set on Sunday instead of Monday. [#419]
 
 ### Internal Changes
 

lib/fastlane/plugin/wpmreleasetoolkit/helper/github_helper.rb

@@ -87,10 +87,25 @@ def self.create_milestone(repository, newmilestone_number, newmilestone_duedate,
         days_until_submission = need_submission ? (number_of_days_from_code_freeze_to_release - 3) : newmilestone_duration
         submission_date = newmilestone_duedate.to_datetime.next_day(days_until_submission)
         release_date = newmilestone_duedate.to_datetime.next_day(number_of_days_from_code_freeze_to_release)
-        comment = "Code freeze: #{newmilestone_duedate.to_datetime.strftime('%B %d, %Y')} App Store submission: #{submission_date.strftime('%B %d, %Y')} Release: #{release_date.strftime('%B %d, %Y')}"
+        comment = <<~MILESTONE_DESCRIPTION
+          Code freeze: #{newmilestone_duedate.to_datetime.strftime('%B %d, %Y')}
+          App Store submission: #{submission_date.strftime('%B %d, %Y')}
+          Release: #{release_date.strftime('%B %d, %Y')}
+        MILESTONE_DESCRIPTION
 
         options = {}
-        options[:due_on] = newmilestone_duedate
+        # == Workaround for GitHub API bug ==
+        #
+        # It seems that whatever date we send to the API, GitHub will 'floor' it to the date that seems to be at
+        # 00:00 PST/PDT and then discard the time component of the date we sent.
+        # This means that, when we cross the November DST change date, where the due date of the previous milestone
+        # was e.g. `2022-10-31T07:00:00Z` and `.next_day(14)` returns `2022-11-14T07:00:00Z` and we send that value
+        # for the `due_on` field via the API, GitHub ends up creating a milestone with a due of `2022-11-13T08:00:00Z`
+        # instead, introducing an off-by-one error on that due date.
+        #
+        # This is a bug in the GitHub API, not in our date computation logic.
+        # To solve this, we trick it by forcing the time component of the ISO date we send to be `12:00:00Z`.
+        options[:due_on] = newmilestone_duedate.strftime('%Y-%m-%dT12:00:00Z')
         options[:description] = comment
         github_client().create_milestone(repository, newmilestone_number, options)
       end