Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-209

Problem with cvs: checkout aborted: Can't parse date/time

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Critical Critical
    • core
    • None
    • Platform: All, OS: All

      This problem happens with version 1.67. It works fine in 1.66 and older versions.
      With CVS, checkout fails with the following message:

      [FOO] $ cvs -Q -z9 -d :extssh:USERNAME@SERVER:/FOO co -d workspace -D Tuesday,
      December 19, 2006 12:21:13 PM GMT-03:00 FOO
      cvs [checkout aborted]: Can't parse date/time: Tuesday, December 19, 2006
      12:21:13 PM GMT-03:00
      ERROR: CVS failed. exit code=1

      It seems Hudson tries to send the date (-D Tuesday, December 19, 2006 12:21:13
      PM GMT-03:00), but it can't be parsed. This parameter is not used in older
      versions of Hudson.

          [JENKINS-209] Problem with cvs: checkout aborted: Can't parse date/time

          Can you tell us the version of cvs on the server?

          Kohsuke Kawaguchi added a comment - Can you tell us the version of cvs on the server?

          ldeseta added a comment -

          The server is an AIX 5. CVS version on server:

          Concurrent Versions System (CVS) 1.11.17 (client/server)

          ldeseta added a comment - The server is an AIX 5. CVS version on server: Concurrent Versions System (CVS) 1.11.17 (client/server)

          Can you try a few other formats to see if they work?

          Does it accept RFC822 format (which is probably the most common format) like
          "Sun, 06 Nov 1994 08:49:37 GMT"?

          Kohsuke Kawaguchi added a comment - Can you try a few other formats to see if they work? Does it accept RFC822 format (which is probably the most common format) like "Sun, 06 Nov 1994 08:49:37 GMT"?

          ldeseta added a comment -

          I tried it at the command line.

          The server supports both formats: the one used by Hudson, and the one you
          proposed to try.

          The problem seems to be with the GMT. These two strings are accepted:
          Tuesday, December 19, 2006 12:21:13 PM GMT
          Tue, 19 Dec 2006 12:21:13 GMT

          BUT, when I set the right GMT, it stops working. The following strings are not
          accepted, and cause a parse error:
          Tuesday, December 19, 2006 12:21:13 PM GMT-03:00 (used by Hudson)
          Tue, 19 Dec 2006 12:21:13 GMT-03:00

          (notice the GMT-03:00 at the end)

          ldeseta added a comment - I tried it at the command line. The server supports both formats: the one used by Hudson, and the one you proposed to try. The problem seems to be with the GMT. These two strings are accepted: Tuesday, December 19, 2006 12:21:13 PM GMT Tue, 19 Dec 2006 12:21:13 GMT BUT, when I set the right GMT, it stops working. The following strings are not accepted, and cause a parse error: Tuesday, December 19, 2006 12:21:13 PM GMT-03:00 (used by Hudson) Tue, 19 Dec 2006 12:21:13 GMT-03:00 (notice the GMT-03:00 at the end)

          Jesse Glick added a comment -

          Strange. My Hudson installation sends e.g.

          $ cvs -q -z9 update -PdC -D Tuesday, December 19, 2006 8:32:44 PM GMT

          That is JDK 5 on Linux, in GMT timezone since it's a server.

          What JRE are you using? And what timezone is reported by "date" from a shell?

          Hudson is simply calling:

          DateFormat.getDateTimeInstance(DateFormat.FULL, DateFormat.FULL,
          Locale.US).format(date)

          I thought this was safe enough, but perhaps some other format would be safer for
          CVS?

          Jesse Glick added a comment - Strange. My Hudson installation sends e.g. $ cvs -q -z9 update -PdC -D Tuesday, December 19, 2006 8:32:44 PM GMT That is JDK 5 on Linux, in GMT timezone since it's a server. What JRE are you using? And what timezone is reported by "date" from a shell? Hudson is simply calling: DateFormat.getDateTimeInstance(DateFormat.FULL, DateFormat.FULL, Locale.US).format(date) I thought this was safe enough, but perhaps some other format would be safer for CVS?

          ldeseta added a comment -

          I'm using Hudson with JDK 5 on Windows.

          System property "user.timezone" is set to "GMT-03:00" (thats my timezone).

          That's why DateFormat is adding that "GMT-03:00" to my string. "user.timezone"
          can be overriden with System.setProperty("user.timezone","GMT"). But I don't
          know if that's a good idea... =)

          ldeseta added a comment - I'm using Hudson with JDK 5 on Windows. System property "user.timezone" is set to "GMT-03:00" (thats my timezone). That's why DateFormat is adding that "GMT-03:00" to my string. "user.timezone" can be overriden with System.setProperty("user.timezone","GMT"). But I don't know if that's a good idea... =)

          Jesse Glick added a comment -

          I see. The CVS manual claims that it "[supports] a wide variety of date formats"
          but apparently this does not extend to whatever Windows uses on your machine.

          Jesse Glick added a comment - I see. The CVS manual claims that it " [supports] a wide variety of date formats" but apparently this does not extend to whatever Windows uses on your machine.

          I recommend using RFC822 format, which is "Sun, 06 Nov 1994 08:49:37 GMT".
          This is the format used in e-mails and HTTP headers, and I'd say cvs wouldn't
          dare to say it supports "a wide variety of date formats" if it leaves out RFC822.

          Kohsuke Kawaguchi added a comment - I recommend using RFC822 format, which is "Sun, 06 Nov 1994 08:49:37 GMT". This is the format used in e-mails and HTTP headers, and I'd say cvs wouldn't dare to say it supports "a wide variety of date formats" if it leaves out RFC822.

          Jesse Glick added a comment -

          RFC822 format would be possible, as would be ISO8601. But the simplest fix seems
          to be to just set the timezone explicitly to UTC.

          Checking in www/changelog.html;
          /shared/data/ccvs/repository/hudson/www/changelog.html,v <-- changelog.html
          new revision: 1.301; previous revision: 1.300
          done
          Checking in main/core/src/main/java/hudson/scm/CVSSCM.java;
          /shared/data/ccvs/repository/hudson/hudson/main/core/src/main/java/hudson/scm/CVSSCM.java,v
          <-- CVSSCM.java
          new revision: 1.15; previous revision: 1.14
          done

          Jesse Glick added a comment - RFC822 format would be possible, as would be ISO8601. But the simplest fix seems to be to just set the timezone explicitly to UTC. Checking in www/changelog.html; /shared/data/ccvs/repository/hudson/www/changelog.html,v <-- changelog.html new revision: 1.301; previous revision: 1.300 done Checking in main/core/src/main/java/hudson/scm/CVSSCM.java; /shared/data/ccvs/repository/hudson/hudson/main/core/src/main/java/hudson/scm/CVSSCM.java,v <-- CVSSCM.java new revision: 1.15; previous revision: 1.14 done

            jglick Jesse Glick
            ldeseta ldeseta
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved: