Current darcs-stable says:

darcs record --all --pipe "web/cs.allmydata.com/account.php" darcs: bad date: 2006/01/19 21:14:20 UTC - (line 1, column 20):
unexpected " "
expecting end of input
... [Error 256]

When for the same input, darcs 1.0.5 succeeds.

Regards,

Zooko

You mean darcs-unstable, right?

This is either an old bug exposed by new code, or a feature, depending on what
cvs_date_time is actually supposed to parse.
 
The darcs code from 1.0.5 only parsed enough of the string to get a succesful
result, so for example, given the string '2006/01/19 21:14:20 UTC', it parses up
to the time and returns because it's happy, even though there is ' UTC' that it
hasn't parsed yet.

With my ISO-8601 patch, I also threw in code to require the entire date string
to be parsed.  Since the cvs_date_time function does not support timezone
strings, the example you gave now fails.

So if I understand this correctly, the fix is either to add timezone support to
cvs_date_time or to say that this date is *supposed* to fail and be happy. 
Opinions?

I don't know what the cvs_date_time function is, but is CVS outputting this
string?  "2006/01/19 21:14:20 UTC"

If so, is there some reason that darcs isn't parsing that string?

Yes, I meant darcs-unstable.  My mistake.

Sorry, I wasn't being very helpful.  

cvs_date_time is the part of the darcs date parsing code which parses CVS dates,
but I have no idea what this is supposed to mean.  Certainly not the kinds of
dates CVS accepts as input, because CVS accepts a whole bunch of stuff and the
cvs_date_time function is very restricted.  For instance, it does not parse
timezone strings.

My guess is that it is not supposed to and that this function serves only to
parse the kind of dates tha CVS outputs (for instance, between $Id:$). I looked
at a random CVS file with such a directive and that date does not have the
timezone string.

So to sum up, unless I'm mistaken, this is technically not a bug.  However, we
might consider making the date parser flexible enough to support such input.

Okay, so the context was that I was using tailor.py to convert an SVN repository
into a darcs repository when this bug happened.  So apparently SVN emits time
stamps of that format.  If darcs 1.0.6 would continue to parse them at least as
well as darcs 1.0.5 currently does then tailor.py can continue to work as is.

On Thu, Jan 19, 2006 at 11:31:24PM +0000, Eric Kow wrote:
> My guess is that it is not supposed to and that this function serves only
> to parse the kind of dates tha CVS outputs (for instance, between
> $Id:$). I looked at a random CVS file with such a directive and that date
> does not have the timezone string.

Right, I think I wrote it when working on cvs2darcs, to make darcs accept
the dates that cvs outputs.

> So to sum up, unless I'm mistaken, this is technically not a bug.
> However, we might consider making the date parser flexible enough to
> support such input.

I'd still call it a regression.  In general, parsing of time zones is a
pain (I believe there are different time zones with the same abbreviation),
but we've already got a hokey time zone parser, and at a minimum we could
add that to the cvs_date_parser.
-- 
David Roundy
http://www.darcs.net

For tailor's current purposes, correctly parsing UTC timestamps would suffice.

On Fri, Jan 20, 2006 at 02:17:20PM +0000, Zooko wrote:
> For tailor's current purposes, correctly parsing UTC timestamps would
> suffice.

Right, which would be handled by the existing (hokey) code, which is also
why I suggested we just go with that.
-- 
David Roundy
http://www.darcs.net

Ok.  Patches sent.  Hokey code used.

I upgraded to the latest stable snapshot of darcs, and my svn<->darcs
synchronizer broke.  I had to obliterate the following patch and all patches
that depend upon it in order to get running again:

Pulling from "http://www.abridgegame.org/repos/darcs"...
Welcome to the darcs darcs repository!

This is the stable release branch.
**********************
Would pull the following changes:
Wed Dec 28 04:30:40 PST 2005  Eric Kow <eric.kow@gmail.com>
  * Partial implementation of iso 8601 dates
  (issue31) - first step 
  
  reluctant to implement (ambiguous!): 
    * years > 9999  
    * truncated representations with implied century (89 for 1989) 
  unimplemented: 
    * time intervals -- this might be good to have in darcs
    * negative dates (BC)                    
  

Wed Dec 28 13:09:42 PST 2005  Eric Kow <eric.kow@gmail.com>
  * Extended date matching functionality. 
  (issue31 and RT #34)
  
  Now accepts ISO 8601 intervals (mostly) as well as a larger subset of
  English (including times like "yesterday at noon").
  
  Note: also includes corrections to ISO 8601 date/time parsing, using
  a more elegant technique of building dates up. 
  

Fri Jan 13 18:10:17 PST 2006  Jason Dagit <dagit@codersbase.com>
  * Added author to darcs record commandline in dateparser.sh

Fri Jan 13 18:13:27 PST 2006  Jason Dagit <dagit@codersbase.com>
  * dateparser.sh only tries to delete tmp if it exists

Sun Jan 29 13:06:35 PST 2006  Eric Kow <eric.kow@gmail.com>
  * Remove '4 score, 7 years ago' from dateparser test.

Sun Jan 29 13:07:01 PST 2006  Eric Kow <eric.kow@gmail.com>
  * Correct dateparser test's self-cleanup.
  
  The dateparser test was not properly removing its own tmp directory,
  causing it to be a pain when using the tests/tests_to_run mechanism.
  

Sat Feb 11 11:45:21 PST 2006  Eric Kow <eric.kow@gmail.com>
  * Detect dates which overflow.  Throw a more helpful error message.
  
  An example of a date which overflows is "105 years ago" on my system.
    
  For reference: The "problem" is not so much Haskell's System.Time, but
  in the underlying C library.  System.Time uses Integer to represent
  ClockTime, so theoretically this number can be as big as we want.
  However, the function addToClockTime makes a call to 'mktime' (time.h)
  to get a value for the number of seconds elapsed since 1970.  And this
  value is of a fixed-size type (time_h).  If the number of seconds
  overflows, mktime returns -1 to indicate an error.  This is detected by
  System.Time and propagated up as a user error "Time.toClockTime: invalid
  input".

My fault.  Forgotten patches on their way to darcs stable.

fixed in 1.0.6
Sat Jan 21 00:33:27 CET 2006  Eric Kow <eric.kow@gmail.com>
  * Add time zone support for CVS date parsing. (issue104)