[darcs-devel] [issue220] missing inventories file in repo for darcs project

Eric Y. Kow eric.kow at gmail.com
Thu Aug 3 01:32:54 PDT 2006


Sorry for the long delay,

I've finally had a chance to look at this.  Thanks for your analysis
Juliusz!  I should have thought about that: date stuff is used in
patch representations, so making changes in date stuff is not as
innocent and harmless as it looks.

On Thu, Jul 13, 2006 at 20:15:31 +0200, Juliusz Chroboczek wrote:
> > I've got the file
> >
> >   20030921115726-53a90-7d65b741dd9d81ff290ee5423046dd53f783a180.gz
>              ^
> >
> > but with your recent changes, it's trying to open
> >
> >   20030921155726-53a90-7d65b741dd9d81ff290ee5423046dd53f783a180.gz
>              ^

[minor snippage]

> The problem is the digit ``1'' underlined above, which has become a
> ``5''.  If you look at showIsoDateTime in IsoDate, you'll notice that
> this is the last digit of the hour, which means that the new Darcs is
> formatting dates with a four hour offset with respect to the old
> Darcs.

It seems the cleanDate patch and the assume-local-timezone patch are
independent of each other.  This bug is not affected by assume-local-
timezone (*)

> Eric, I think you're going to have to implement two versions of
> cleanDate: one that uses GMT (UTC, whatever) for on-disk structures,
> and one that uses local time for human interaction.  

The first question I asked myself is why we are using cleanDate in
PatchInfo.make_filename.  After all, the date comes from a PatchInfo,
right? The impression I get is that the date format inside a patch has
changed.  Around 2003, we used to write them in the human-readable way,
and sometime later, we must have switched to a terse ISO format like
20031110125819.

> But I don't understand why the offset is four hours (I'm at GMT+2).

It's because the date being parsed was EDT, aka UTC-4.  In other words,
the new cleanDate was doing the right thing: converting the timezone
instead of just truncating it.  But in this case, doing the right thing
would break old patches.

So what I propose is the following:

There are only three uses of cleanDate.  The other two are for human
interaction.  So rather than use cleanDate in this function, and
rather than write a second cleanDate with incorrect behaviour, we
simply slap a showIsoDateTime.readDate into PatchInfo.make_filename
and put a comment saying that this is wrong, but we need it for old
patches.

How does that sound?

(*) I also think I should rewrite assume-local-timezone, but that's
    just so we avoid shooting ourselves in the foot later on.

-- 
Eric Kow                     http://www.loria.fr/~kow
PGP Key ID: 08AC04F9         Merci de corriger mon français.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
Url : http://lists.osuosl.org/pipermail/darcs-devel/attachments/20060803/45cb7595/attachment.pgp


More information about the darcs-devel mailing list