You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ensure Milestone due_on always gets set to desired date (#133)
The "Should have the expected due_on date" UT was failing, but
only at certain times of the day. Further investigation uncovered
this support forum post:
https://github.community/t5/How-to-use-Git-and-GitHub/Milestone-quot-Due-On-quot-field-defaults-to-7-00-when-set-by-v3/m-p/6901
In the event that the post goes away at some point, I will archive
what it says here:
> This is an artifact of how GitHub was originally designed.
> To my recollection, all timestamps in the database are
> normalized to Pacific time. So yes, this is the expected behavior.
> [The time used will vary] because midnight Pacific time is
> 7AM or 8AM UTC time depending on whether Pacific time is in
> daylight savings or not on that date.
Given this information, the problem was then quite clear.
Examples:
* If you set 'due_on' to be '2020-09-24T06:59:00Z',
GitHub considers that to be '2020-09-23T07:00:00Z'
(the previous day!!)
* And if you set 'due_on' to be '2020-09-24T07:01:00Z',
GitHub considers that to be '2020-09-24T07:00:00Z'
(the correct day)
Given this, I've modified `New-GitHubMilestone` and `Set-GitHubMilestone`
to drop the user's provided time (since GitHub does that anyway), and
instead always add 9 hours from midnight (UTC) to the provided
date, which bypasses having to check if we're in daylight savings time
or not.
I then added two additional UT's to ensure we don't lose that functionality.
Finally, I updated the documentation in those methods to try to make it more
clear to users what is going to happen with the date/time that they provide.
Fixes#92
0 commit comments