commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Caswell" <st...@mungoknotwise.com>
Subject RE: [lang] DateUtils parseCVS with time format
Date Wed, 06 Aug 2003 00:49:19 GMT
OK, after a bit of head scratching, and staring at the code for a while, I
think I figured out how I screwed up the test. When I first discovered that
parseCVS with "h:mm z" format was returning the time on Jaunary 1, 1970, I
naively figured I could correct my assert by normalizing my calendar to that
date. What I failed to account for (I think) was the different in DST.

I couldn't figure out a straightforward way to test parseCVS for this format
the way the other tests are done, by using the current date and time, so I
changed the tests to try a series of hard-coded times with different
timezones. This seems to work in at lease my timezone and Stephen's.

This still leaves open the question of whether parseCVS with this format
should behave in this manner (applying the time to 1/1/70), which I'll open
as a Bugzilla issue.


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: Monday, August 04, 2003 3:16 PM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] DateUtils parseCVS with time format
> 
> 
> Error happens on Windows98, Sun JDK 1.4.1.
> Does not happen on JDK 1.3.1.
> Stephen
> 
> ----- Original Message -----
> From: "Stephen Colebourne" <scolebourne@btopenworld.com>
> To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> Sent: Monday, August 04, 2003 8:54 PM
> Subject: Re: [lang] DateUtils parseCVS with time format
> 
> 
> > 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(DateUt
> ilsTest.java:6
> > 92)
> >  at
> >
> org.apache.commons.lang.time.DateUtilsTest.testParseCVS(DateUt
> ilsTest.java:4
> > 22)
> >  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)  at
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess
> orImpl.java:39
> > )
> >  at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth
> odAccessorImpl
> > .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
> > >
> >
> >
> > 
> ---------------------------------------------------------------------
> > 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