A quick look at the source suggests that this must be a bug in the GHC
library but, if so, it seems worth recording and I can't see an existing
bug report.  I found that matching failed in my own repo on a BST time
stamp, but not a GMT one.  Here's an example in the darcs repo with a
recently-built binary:

  $ ./darcs --version
  2.2.0pre2 (+ 38 patches)
  $ ghc --version
  The Glorious Glasgow Haskell Compilation System, version 6.8.2
  $ ./darcs diff --match 'date "Thu Oct 23 06:09:26 BST 2008"'

  darcs failed:  Couldn't match pattern "date "Thu Oct 23 06:09:26 BST 2008""
  $ darcs diff --match 'date "Thu Oct 23 05:09:26 GMT 2008"'|head -2
  Thu Oct 23 06:09:26 BST 2008  Trent W. Buck <trentbuck@gmail.com>
    * Miscellaneous refactoring.

For what it's worth, it isn't a problem with glibc:

  $ /lib64/libc.so.6 --version|head -1
  GNU C Library development release version 2.8.90, by Roland McGrath et al.
  $ date -d "Thu Oct 23 06:09:26 BST 2008"
  Thu Oct 23 06:09:26 BST 2008
  $ date -d "Thu Oct 23 05:09:26 GMT 2008"
  Thu Oct 23 06:09:26 BST 2008

On Sun, Jan 11, 2009 at 17:20:44 -0000, Dave Love wrote:
> A quick look at the source suggests that this must be a bug in the GHC
> library but, if so, it seems worth recording and I can't see an existing
> bug report.  I found that matching failed in my own repo on a BST time
> stamp, but not a GMT one.  Here's an example in the darcs repo with a
> recently-built binary:

Our support for timezone strings is fairly limited (it's a hard coded
list).  I think a simple, pragmatic way to deal with this might be to
improve our documentation on this point, encourage people to use ISO
8601 dates for matching (I realise this means you can't just feed dates
darcs outputs back to darcs), and mark this as wont-fix

Eric Kow <bugs@darcs.net> writes:

> Our support for timezone strings is fairly limited (it's a hard coded
> list).  I think a simple, pragmatic way to deal with this might be to
> improve our documentation on this point, encourage people to use ISO
> 8601 dates for matching (I realise this means you can't just feed dates
> darcs outputs back to darcs), and mark this as wont-fix

I'm not sure why I was misled that the relevant code wasn't in darcs.
Anyway, I think you can do something reasonable using the same set of
zones as GNU date(1) et al; I'll send a patch for the coverage and doc.
Also, I'll force UTC in the Emacs support where I initially found the
problem.

The following patch updated the status of issue1311 to be resolved:

* Resolve issue1311:  Use time zones from GNU coreutils; improve doc. 
Ignore-this: 883bc4ccdb1d27fde14ec9c76a4d2a45

The following patch updated the status of issue1311 to be resolved:

* Resolve issue1311:  Use time zones from GNU coreutils; improve doc. 
Ignore-this: 883bc4ccdb1d27fde14ec9c76a4d2a45