Use UTC for future release date #926
Conversation
9b617c2 to
1139c1b
Compare
| end | ||
|
|
||
| it { is_expected.to eq(["2.0.0", "2.0.0", Time.gm(2020, 12, 28, 3)]) } | ||
| end |
There was a problem hiding this comment.
Thanks for adding a spec, this helps catch regressions. But, perhaps a code comment, or an "it" being described with a note that captures the essence of the change (should always use UTC since GitHub uses UTC for the things we care about, etc).
There was a problem hiding this comment.
lol, I was focusing what was being tested and the reason for this has been completely lost!
I amended my commit to add a context and an explicit comment. Thanks!
There was a problem hiding this comment.
This looks perfect, and will guide the interested reader in the future.
Thanks, @smortex for the repairs!
1139c1b to
0ed7f4c
Compare
When using future releases, the current local date is writen in the generated CHANGELOG. This is usualy done as part of releasing a new version, that is a few seconds before a that version is tagged and that tag is pushed to GitHub. On next version bump, that previous tag exist and it's date is read from GitHub which provide this information in Coordinated Universal Time (UTC). Depending on the time-zone of the user, the date of these two Ruby Time objects may be different, leading to an unexpected change in the previous entry of the CHANGELOG. To avoid this, convert the local time to UTC when we do not have an actual tag time to use.
0ed7f4c to
2a44a8f
Compare
| end | ||
|
|
||
| it { is_expected.to eq(["2.0.0", "2.0.0", Time.gm(2020, 12, 28, 3)]) } | ||
| end |
There was a problem hiding this comment.
This looks perfect, and will guide the interested reader in the future.
Thanks, @smortex for the repairs!
When using future releases, the current local date is writen in the
generated CHANGELOG. This is usualy done as part of releasing a new
version, that is a few seconds before a that version is tagged and
that tag is pushed to GitHub.
On next version bump, that previous tag exist and it's date is read from
GitHub which provide this information in Coordinated Universal Time
(UTC).
Depending on the time-zone of the user, the date of these two Ruby Time
objects may be different, leading to an unexpected change in the
previous entry of the CHANGELOG.
To avoid this, convert the local time to UTC when we do not have an
actual tag time to use.