[root]/src/java/org/apache/commons/lang/time
| Author | Changes | Lines of Code | Lines per Change |
|---|---|---|---|
| Totals | 179 (100.0%) | 7508 (100.0%) | 41.9 |
| bayard | 60 (33.5%) | 3719 (49.5%) | 61.9 |
| scolebourne | 46 (25.7%) | 3068 (40.9%) | 66.6 |
| ggregory | 42 (23.5%) | 335 (4.5%) | 7.9 |
| stevencaswell | 16 (8.9%) | 311 (4.1%) | 19.4 |
| psteitz | 7 (3.9%) | 67 (0.9%) | 9.5 |
| fredrik | 1 (0.6%) | 3 (0.0%) | 3.0 |
| dirkv | 6 (3.4%) | 3 (0.0%) | 0.5 |
| niallp | 1 (0.6%) | 2 (0.0%) | 2.0 |
Applying test and fix for LANG-315
3 lines of code changed in:
Oops, javadoc typo
1 lines of code changed in:
Fixing javadoc warnings from checkstyle
8 lines of code changed in:
Statement unnecessarily nested within else clause. The corresponding then clause does not complete normally.
1 lines of code changed in:
Fix javadoc link
2 lines of code changed in:
Applying test for #LANG-303, and a fix.
12 lines of code changed in:
Fixed import. Also optimised list.toArray(..) to use new Token[list.size()] so that the passed in array is used and not reflection. Latter reported by FindBugs
3 lines of code changed in:
More tests, more bugfixes (aka rewrite of the guts).
It's looking much better, the only edge case that throws it for a loop is if things start on the 29th of February in a year. I've hacked it in the day mode, but I'm not sure why I had to do that - however I trust the brute force test to be right in day mode.
In month mode, it's even trickier as to what the correct answer is. How many months between 29th Feb and 28th of Feb the next year? The answer is 11, or with days included it's 11 months and 28 days. I can't see any reason to define that better, so I'm declaring that law.
Things are weird if you start on Feb 29 :)
60 lines of code changed in:
Updated comment
2 lines of code changed in:
Let a few tab characters slip in - Eclipse wasn't configured yet. Replacing with spaces.
5 lines of code changed in:
More unit tests and bugfixes. The currently failing test is commented out, so more bugfixes to come.
33 lines of code changed in:
More tests added to DurationFormatUtilsTest and discovered bugs fixed in the DurationFormatUtils.formatPeriod method.
21 lines of code changed in:
Added javadoc to explain the quandry in how to count month/day differences
16 lines of code changed in:
Removing my @author tags
0 lines of code changed in:
formetted to formatted - typo fix
1 lines of code changed in:
Adding a unit test for #LANG-281 and a fix. The fix involves removing the reduceAndCorrect method. It appears that this method was doing sod all - which is worrying as it used to be important. I'm guessing that it was a bad fix for a bug that was then subsequently fixed with other code. I'll create a JIRA issue to create more tests to test out the +31 block of code.
8 lines of code changed in:
Fixing the ASF copyright and placing it in the NOTICE file
36 lines of code changed in:
Change "Copyright ....-2005" to "Copyright ....-2006"
6 lines of code changed in:
Javadoc comments for serialVersionUID.
5 lines of code changed in:
Adds missing serialVersionUID to Serializable classes.
A note from http://wiki.eclipse.org/index.php/FAQ_Why_does_the_Eclipse_compiler_create_a_different_serialVersionUID_from_javac%3F:
If you don’t explicitly define a serialVersionUID, the language requires that the VM generate one, using some function of all field and method names in the class. The problem is, the compiler generates some synthetic methods that you never see in your source file, and there is no clear specification for how these synthetic method names are generated. Any two compilers are likely to generate different method names, and so the serialVersionUID will be different. Bottom line: Always define the serialVersionUID explicitly in your source files.
2 lines of code changed in:
(94 more)
