commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [lang] DateUtils parseCVS with time format
Date Mon, 04 Aug 2003 19:54:27 GMT
There was 1 failure:
1)
testParseCVS(org.apache.commons.lang.time.DateUtilsTest)junit.framework.Asse
rtionFailedError: parseCVS format h:mm z expected Thu Jan 01 20:54:00 GMT
1970 but got Thu Jan 01 21:54:00 GMT 1970
 at
org.apache.commons.lang.time.DateUtilsTest.assertEquals(DateUtilsTest.java:6
92)
 at
org.apache.commons.lang.time.DateUtilsTest.testParseCVS(DateUtilsTest.java:4
22)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
 at org.apache.commons.lang.time.TimeTestSuite.main(TimeTestSuite.java:80)

----- Original Message -----
From: <steve@mungoknotwise.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Monday, August 04, 2003 1:30 PM
Subject: Re: [lang] DateUtils parseCVS with time format


> Quoting Stephen Colebourne <scolebourne@btopenworld.com>:
>
> > The parseCVS h:mm z now fails on my PC.
> >
> > Locale en_GB, timezone Europe/London. GMT+01:00
>
> Does the actual method fail, or the test? I tweaked the DateUtils class,
but I
> didn't touch that part of the parseCVS method. I did add a test for "h:mm
z",
> but it passed on my system (I don't have the locale right in front of me
at the
> moment).
>
> >
> > Stephen
> >
> > ----- Original Message -----
> > From: "Steven Caswell" <steve@mungoknotwise.com>
> > To: "'Jakarta Commons Developers List'" <commons-dev@jakarta.apache.org>
> > Sent: Monday, August 04, 2003 1:11 AM
> > Subject: RE: [lang] DateUtils parseCVS with time format
> >
> >
> > And I should have said that I don't know the CVS behavior either.
> >
> > So I guess the next question is how closely should we try to mimic the
CVS
> > format, given that this is the parseCVS method. Are we trying to
approximate
> > the behavior, or do we believe someone will need it to behave as it were
> > strictly compliant to CVS behavior?
> >
> >
> > Steven Caswell
> > steve@mungoknotwise.com
> > a.k.a Mungo Knotwise of Michel Delving
> > "One ring to rule them all, one ring to find them..."
> >
> >
> > > -----Original Message-----
> > > From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> > > Sent: Sunday, August 03, 2003 6:58 PM
> > > To: Jakarta Commons Developers List
> > > Subject: Re: [lang] DateUtils parseCVS with time format
> > >
> > >
> > > I don't know the CVS answer, but todays date makes more sense
> > > here. Stephen
> > >
> > > ----- Original Message -----
> > > From: "Serge Knystautas" <sergek@lokitech.com>
> > > To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> > > Sent: Monday, August 04, 2003 12:46 AM
> > > Subject: Re: [lang] DateUtils parseCVS with time format
> > >
> > >
> > > > Steven Caswell wrote:
> > > > > One of the supported formats for input to parseCVS is h:mm z. The
> > > > > method parses the time correctly, but the date is left as the
> > > > > default of
> > > January 1,
> > > > > 1970. Does this make sense, or does it make sense to have
> > > it fill in
> > > > > the current date? Since the API is silent on the expected
> > > behavior,
> > > > > it is difficult to test the API for correctness.
> > > >
> > > > Do you know how CVS works?  does it set the date as that
> > > time in the
> > > > last 24 hours, or does it always set today's date?  There are some
> > > > unit tests that are based on the current time, so I can put
> > > together
> > > > unit tests and correct this behavior once I'm sure what it
> > > should be.
> > > >
> > > > --
> > > > Serge Knystautas
> > > > President
> > > > Lokitech >> software . strategy . design >>
> > > http://www.lokitech.com/
> > > > p. 1.301.656.5501 e. sergek@lokitech.com
> > > >
> > > >
> > > >
> > > >
> > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> > >
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


Mime
View raw message