groovy

Do you want contribution on this issue. I am interested in using Date/Time category API for a Groovy DSL I am writing.

Tahir, yes, if you could contribute some unit tests, that would be wonderful, and that's a nice way to discover the capabilities of this date/time support.

Alright.
I am new to this project. Just built groovy-1.1-BETA-1 from source download (svn was very slow for me).

Looked around the source. I think org.codehaus.groovy.runtime.TimeCategory (in src/main) is our class. And the test will go in the same package of src/test folder?

Yes, TimeCategory is the one we have to test.
The test should go in the same package under the test directory.
You can take some inspiration from the original module which was related to GData:
http://fisheye.codehaus.org/browse/groovy/trunk/groovy/modules/gdata/src/test/groovy/google/gdata/DurationTest.groovy?r=3847

OK.
DurationTest seems to be a good starting point. Actually it appears that tests in DurationTest are not in any way specific to GData. If that proves to be the case I can start by simply copying the existing tests and then look for the usages not yet covered.

John, I am happy to keep an eye out for this issue - assigning to me. Let me know if that's not OK - just take back if need be. PaulK.

Hi Tahir, I don't know if you have had time to look at this yet or not. It would be great if you can find the time.

Things you should note:

• the fixme_testDurationArithmetic() method won't be run as part of the normal test suite (just remove the 'fixme_' part of the name) to enable it. This was because it was breaking the build whenever daylight saving was starting or stopping.
• you can find out coverage information about what is tested from the coverage report on the CI server: http://build.canoo.com/groovy/artifacts/20070617013352/reports/cobertura/index.html

Hi Paul,
Actually I was not able to find time. But hopefully will be able to nab it during the coming weekend.

I looked at the Cobertura report... may I submit a patch with a test for the minus method (which has no coverage) without also adding tests for the daylight savings issues? Or do you require one patch that has gets the class to 100%?

I am having trouble with the TimeCategory.getMonth( ) method. According to my tests, the 1.month method should return the object representing the current month (October currently, which has 31 days). However, I am seeing too many milliseconds when I call getMilliseconds() on the result.

Here is the test method that is failing (just sample code to demonstrate the issue):

/**

• Months evaluates relative to the current date, so if this is
• July then months has 31 days. If this is November then months
• has 30 days. The test uses java.util.Calendar to determine if
• groovy works correctly.
• WARNING: This test will sometimes fail if the month changes during
• the execution of the test method. Incredibly rare event.
  */
  void testMonths()
  Unknown macro: { use(TimeCategory) { def daysInMonth = Calendar.getInstance().getActualMaximum(Calendar.DAY_OF_MONTH) def actual = new BigInteger(1.month.toMilliseconds()); def expected = new BigInteger(daysInMonth); expected = expected.multiply(new BigInteger(1000)) //milliseconds expected = expected.multiply(new BigInteger(60)) //seconds expected = expected.multiply(new BigInteger(60)) //minutes expected = expected.multiply(new BigInteger(24)) //hours println("actual = " + actual); println("expected = " + expected); assert actual == expected } }

The assertion fails. The output is:
actual = 2682000000
expected = 2678400000

It is as if the TimeCategory is calculating the number of days in October as 31.041 and two thirds.

Any suggestions?

More tests, even not full coverage, is great!

Re: actual = 2682000000, expected = 2678400000

It is out by an hour. This is to be expected if your system is set to a timezone which has daylight saving starting/ending.

Added unit tests for TimeCategory. Date and Duration arithmetic should now be at 100%. The timezone and DST calculations are not tested, but are quite simple calculations.

A user's regional settings, timezone, and DST status should not effect the outcome of these tests.

The test case contains 4 todo notes, which correspond to the places in the test effected by the defect discussed on the mailing list (http://www.nabble.com/TimeCategory-subtraction-not-working--p13246074.html)

Attached file is output of "svn diff" command.

Please let me know if anything is out of order or needs changing.

Thanks for the great Patch. Should be in the next build.