fixing corrupt bzr date?

[Jelmer Vernooij]

On Fri, Mar 30, 2018 at 10:01:53AM -0600, Mats Wichmann wrote:
> 
> so in doing some conversions to, yeah, git (what can you do?) git's
> fast-import crashes on one particular commit.
> 
> >From the log of that:
> 
> fast-import crash report:
>     fast-import process: 19392
>     parent process     : 19391
>     at Fri Mar 30 09:02:38 2018
> 
> fatal: Invalid raw date "1241706289 -34492624" in ident: Mats Wichmann
> <mats at spidey.linux-foundation.org> 1241706289 -34492624
> 
> that is indeed a fascinating looking date with the wonky timezone offset....
> 
> 1241706289 works out to May 7, 2009. So digging around in that area in
> the bzr log I find, just below a May 8 commit:
> 
> ------------------------------------------------------------
> revno: 931
> committer: Mats Wichmann <mats at spidey.linux-foundation.org>
> branch nick: specdb
> timestamp: Wed 1969-12-31 16:00:00 -34492735
> message:
>   fix some constants in newly added IP information (bug 2440)
> ------------------------------------------------------------
> 
> so it seems bzr is confused by whatever got written as well.
> 
> is there anything one can do to fixup the wonky date? or to get
> fast-export to regurgitate it in a form that doesn't crash git - which
> perhaps might be easier?
> 
> I found one LP bug on bzr-fastimport that sounds vaguely familiar
> (https://bugs.launchpad.net/bzr-fastimport/+bug/538933), but it doesn't
> seem to be that the export function is doing things wrong here, it's
> finding bad data to begin with it looks like.
The simplest thing to do would probably be to edit the fastexport
stream after it's been generated and get rid of the incorrect offset
(e.g. just set it to 0). The format is fairly readable, you can
just search for that particular offset.

bzr fastexport could probably do something similar by itself. I wonder
how you ever ended up with that funk offset though...

Jelmer

-- 
Jelmer Vernooij <jelmer at jelmer.uk>
PGP Key: https://www.jelmer.uk/D729A457.asc