A long explanation for a short fix :-)

I'm surprised this hasn't gone wrong before as I saw it as
soon as I wrote a (new) failing test - I guess our web of
generators means it isn't always used in the same way.

Old patch references:

http://bugs.darcs.net/patch1662
http://bugs.darcs.net/patch1771

1 patch for repository darcs-unstable@darcs.net:/opt/darcs/screened:

patch ee42ad9d53fa8cbd938657c8a51b4fa2846bda73
Author: Ganesh Sittampalam <ganesh@earth.li>
Date:   Mon Jul 10 08:44:18 BST 2023
  * tests fix: don't generate random date strings for PatchInfo

  Although we check that they contain a limited range of
  characters that are valid in dates, we don't check that they
  actually parse as dates. As Darcs.Patch.Info.friendlyD parses
  these strings even when just printing out a patch in order to
  shift timezones, this makes these values unusable.

  This follows on from this patch which added the initial
  validation:

  > patch 403698ffdc7b41b9840ccad632915f82a848b644
  > Author: Ben Franksen <ben.franksen@online.de>
  > Date:   Mon Mar 12 22:42:53 CET 2018
  >  * add validation for PatchInfo items, add unit test for parse/unparse

  and this patch which applied a similar fix in another place:

  > patch ba25e53c0bbbe23ab84f07447af346aa5059ecd8
  > Author: Ben Franksen <ben.franksen@online.de>
  > Date:   Fri Nov 16 21:26:05 CET 2018
  >  * fix: insert a valid date when creating anonymous named patch

  In future we could revamp this more so that we can

  (a) generate actual arbitrary dates - though this is unlikely to
      be actually important for tests

  (b) replace validDate with logic that fully parses the date

Attachments

• patch-preview.txt
• tests-fix_-don_t-generate-random-date-strings-for-patchinfo.dpatch

Thanks for this one! Some time ago I generalized the patch tests to include 
quickcheck tests for Named patches, too. These regularly failed with error calls 
because we generated invalid date strings. I hope this will now be fixed and I 
can send and screen them.

Now that we no longer generate (potentially) invalid dates, 
shrinking gives me an "invalid patch name" error (for Named 
RepoPatchV3):

    resolutions are invariant under reorderings: [Failed]
*** Failed! (after 486 tests and 8 shrinks):
Exception while generating shrink-list:
  invalid patch name 
"\n\56451\1256\56529\56570mP\56537\56514\ETBO\56506p\56533\tq\ETB\56
553v\987\56470\DC1\56460\56463\STX\SO\56567\56459\&1:\56559\56469_\5
6505\56547\56457_\56527\56541\56573Jvp\40000R\56449\56495l\56488\565
72\DC1=a\DC2&u\56537\&0\56485=\b\56553\&53"

Do you have a simple fix for that, too?

> Now that we no longer generate (potentially) invalid dates, 
> shrinking gives me an "invalid patch name" error (for Named 
> RepoPatchV3):

> Do you have a simple fix for that, too?

Afraid not, I didn't run into it myself. I had a very quick glance
and I'm not even sure why it happens as shrinkPatchInfo calls
shrink on a ByteString and I don't know what code that ends up
calling.

Self-accepting as it's a test fix that's a definite improvement even if
it doesn't solve all our test generation problems.