Skip to content

Don't drop most of the commit date from ./mach vendor --check-for-update for some hosts - #424

Merged
tomrittervg merged 1 commit into
mozilla-services:masterfrom
tnikkel:dont-drop-commit-date
Sep 25, 2026
Merged

tomrittervg merged 1 commit into
mozilla-services:masterfrom
tnikkel:dont-drop-commit-date

Conversation

@tnikkel

@tnikkel tnikkel commented Sep 17, 2026 •

Copy link
Copy Markdown
Contributor

check_for_update splits mach's " " output on every
space and keeps the second field. For a github-hosted library that second
field is the whole timestamp:

3f3735e3f39c68d33104add994bfe5d055b32e17 2026-09-09T17:56:48Z

googlesource reports commit dates with spaces in them, so there the second
field is only the weekday and the rest of the date is thrown away:

3f3735e3f39c68d33104add994bfe5d055b32e17 Wed Sep 09 17:56:48 2026

dateutil resolves a bare "Wed" against today's date, which is how
https://bugzilla.mozilla.org/show_bug.cgi?id=2070891, filed on 2026-09-10 for
a commit made on 2026-09-09, ended up titled "from 2026-09-16 00:00:00": the
next Wednesday, at midnight. libvpx, aom, irregexp and chromium-cdm are
affected the same way.

host_git.py has the same problem more quietly: git show --format=%ci gives
"2026-09-16 23:20:10 -0500", so there we kept the date and threw away the
time. Rather than make every host agree on one format, parse whatever the
host reports; dateutil already copes with all of them.

…ate for some hosts

`check_for_update` splits mach's "<revision> <timestamp>" output on every
space and keeps the second field. For a github-hosted library that second
field is the whole timestamp:

    3f3735e3f39c68d33104add994bfe5d055b32e17 2026-09-09T17:56:48Z

googlesource reports commit dates with spaces in them, so there the second
field is only the weekday and the rest of the date is thrown away:

    3f3735e3f39c68d33104add994bfe5d055b32e17 Wed Sep 09 17:56:48 2026

dateutil resolves a bare "Wed" against today's date, which is how
https://bugzilla.mozilla.org/show_bug.cgi?id=2070891, filed on 2026-09-10 for
a commit made on 2026-09-09, ended up titled "from 2026-09-16 00:00:00": the
next Wednesday, at midnight. libvpx, aom, irregexp and chromium-cdm are
affected the same way.

host_git.py has the same problem more quietly: `git show --format=%ci` gives
"2026-09-16 23:20:10 -0500", so there we kept the date and threw away the
time. Rather than make every host agree on one format, parse whatever the
host reports; dateutil already copes with all of them.
@tnikkel
tnikkel force-pushed the dont-drop-commit-date branch from 42296a5 to c178bee Compare September 17, 2026 04:43
@tomrittervg
tomrittervg merged commit ba12413 into mozilla-services:master Sep 25, 2026
16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants