Git repo is broken by error commits

[KuzinAndrey]

On some hosts cloning going okey:

# git clone https://github.com/FRRouting/frr/
Cloning into 'frr'...
remote: Enumerating objects: 298564, done.
remote: Counting objects: 100% (556/556), done.
remote: Compressing objects: 100% (221/221), done.
remote: Total 298564 (delta 445), reused 335 (delta 335), pack-reused 298008 (from 3)
Receiving objects: 100% (298564/298564), 181.69 MiB | 11.43 MiB/s, done.
Resolving deltas: 100% (232133/232133), done.
Updating files: 100% (8910/8910), done.

but after that:

# git fsck
Checking ref database: 100% (1/1), done.
Checking object directories: 100% (256/256), done.
error in commit b374a10c2889da751fcef33d1c787d42438ded13: badTimezone: invalid author/committer line - bad time zone
error in commit 5de262a839b04ff4649d4e04784c98c08322d7b4: badTimezone: invalid author/committer line - bad time zone
error in commit 747af764419291c802480665d7a7e918eae8c112: badTimezone: invalid author/committer line - bad time zone
Checking objects: 100% (298564/298564), done.
Checking connectivity: 298564, done.

On some hosts cloning failure:

$ git clone https://github.com/FRRouting/frr/
Cloning into 'frr'...
remote: Enumerating objects: 298564, done.
remote: Counting objects: 100% (556/556), done.
remote: Compressing objects: 100% (221/221), done.
error: object b374a10c2889da751fcef33d1c787d42438ded13: badTimezone: invalid author/committer line - bad time zone
fatal: fsck error in packed object
fatal: fetch-pack: invalid index-pack output

By checkingURL b374a10 i see wrong date for commit Mark Stapp committed on Jan 4, 2121 but:

$ git show b374a10c2889da751fcef33d1c787d42438ded13
commit b374a10c2889da751fcef33d1c787d42438ded13
Author: Mark Stapp <mjs@cisco.com>
Date:   Wed Nov 5 15:17:43 2025 -0500

    build: enable epoll in the event lib by default
    
    Enable epoll by default on platforms where it's present. The
    configure tests fall back to ppoll (or poll) otherwise.
    
    Signed-off-by: Mark Stapp <mjs@cisco.com>

[mjstapp]

Those are odd commits - I wish git had objected at the time, and informed me that it was going to store some bogus metadata. but I think it's not a common issue - I don't believe it's been interfering with normal interactions for the months the condition has existed.