[jira] [Commented] (CLI-312) Inconsistent behaviour in key/value pairs (Java property style)
[
https://issues.apache.org/jira/browse/CLI-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445035#comment-17445035
]
Robert Scholte commented on CLI-312:
As of 1.5.0 [CommandLine.getOptionProperties(Option
option)|https://commons.apache.org/proper/commons-cli/apidocs/org/apache/commons/cli/CommandLine.html#getOptionProperties-org.apache.commons.cli.Option-]
should do exactly this.
> Inconsistent behaviour in key/value pairs (Java property style)
> ---
>
> Key: CLI-312
> URL: https://issues.apache.org/jira/browse/CLI-312
> Project: Commons CLI
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.5
>Reporter: Maarten Mulders
>Priority: Minor
>
> In the Apache Maven project, we used to have an {{Option}} defined like this:
> {code:java}
> Option.builder("D").longOpt("define").hasArg().build()
> {code}
> This allowed our users to define properties using all of these:
> * {{-Dx=1}}
> * {{-Dx}}
> * {{-D x}}
> * {{--define x=1}}
> * {{--define x}}
> Splitting the key/value pairs was something that we did inside Maven
> ([{{MavenCli.java
> #1733}}|https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L1733]
> and [{{MavenCli.java
> #1762}}|https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L1762]).
> In the process of upgrading to Commons CLI 1.5 and moving away from the
> deprecated {{GnuParser}}, we found out that Commons CLI can split argument
> values thanks to the {{valueSeparator}}. We've changed our option declaration
> accordingly:
> {code:java}
> Option.builder("D").longOpt("define").numberOfArgs(2).valueSeparator('=').build()
> );
> {code}
> Unfortunately, this breaks our accepted inputs: {{-Dv -Dw=1 -D x=2 -D y -D
> z=3}} breaks the parsing in Commons CLI:
> {code}
> org.apache.commons.cli.MissingArgumentException: Missing argument for option:
> D
> at
> org.apache.commons.cli.DefaultParser.checkRequiredArgs(DefaultParser.java:231)
> at
> org.apache.commons.cli.DefaultParser.handleOption(DefaultParser.java:394)
> at
> org.apache.commons.cli.DefaultParser.handleShortAndLongOption(DefaultParser.java:467)
> at
> org.apache.commons.cli.DefaultParser.handleToken(DefaultParser.java:542)
> at org.apache.commons.cli.DefaultParser.parse(DefaultParser.java:714)
> at org.apache.commons.cli.DefaultParser.parse(DefaultParser.java:681)
> at org.apache.commons.cli.DefaultParser.parse(DefaultParser.java:662)
> {code}
> From debugging, I've learned that it breaks at the *fifth* occurrence of
> {{-D}} (the one followed by {{z=3}}). It considers the *fourth* occurrence of
> {{-D}} incomplete (having only one value and not two). The strange thing is
> that the *first* occurrence of {{-D}} also has just one value ({{v}}) but
> parsing {{-Dw=1}} does not break over that.
> I can submit a pull request for a bug that demonstrates this, but I have no
> clue how to address it. Also, I don't know if this is actually supposed to
> work. Looking forward to your reaction.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CLI-312) Inconsistent behaviour in key/value pairs (Java property style)
[
https://issues.apache.org/jira/browse/CLI-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17444989#comment-17444989
]
Robert Scholte commented on CLI-312:
Confirmed, this is indeed how Maven handles the -D flags internally, but it
could help with a proper solution here.
> Inconsistent behaviour in key/value pairs (Java property style)
> ---
>
> Key: CLI-312
> URL: https://issues.apache.org/jira/browse/CLI-312
> Project: Commons CLI
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.5
>Reporter: Maarten Mulders
>Priority: Minor
>
> In the Apache Maven project, we used to have an {{Option}} defined like this:
> {code:java}
> Option.builder("D").longOpt("define").hasArg().build()
> {code}
> This allowed our users to define properties using all of these:
> * {{-Dx=1}}
> * {{-Dx}}
> * {{-D x}}
> * {{--define x=1}}
> * {{--define x}}
> Splitting the key/value pairs was something that we did inside Maven
> ([{{MavenCli.java
> #1733}}|https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L1733]
> and [{{MavenCli.java
> #1762}}|https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L1762]).
> In the process of upgrading to Commons CLI 1.5 and moving away from the
> deprecated {{GnuParser}}, we found out that Commons CLI can split argument
> values thanks to the {{valueSeparator}}. We've changed our option declaration
> accordingly:
> {code:java}
> Option.builder("D").longOpt("define").numberOfArgs(2).valueSeparator('=').build()
> );
> {code}
> Unfortunately, this breaks our accepted inputs: {{-Dv -Dw=1 -D x=2 -D y -D
> z=3}} breaks the parsing in Commons CLI:
> {code}
> org.apache.commons.cli.MissingArgumentException: Missing argument for option:
> D
> at
> org.apache.commons.cli.DefaultParser.checkRequiredArgs(DefaultParser.java:231)
> at
> org.apache.commons.cli.DefaultParser.handleOption(DefaultParser.java:394)
> at
> org.apache.commons.cli.DefaultParser.handleShortAndLongOption(DefaultParser.java:467)
> at
> org.apache.commons.cli.DefaultParser.handleToken(DefaultParser.java:542)
> at org.apache.commons.cli.DefaultParser.parse(DefaultParser.java:714)
> at org.apache.commons.cli.DefaultParser.parse(DefaultParser.java:681)
> at org.apache.commons.cli.DefaultParser.parse(DefaultParser.java:662)
> {code}
> From debugging, I've learned that it breaks at the *fifth* occurrence of
> {{-D}} (the one followed by {{z=3}}). It considers the *fourth* occurrence of
> {{-D}} incomplete (having only one value and not two). The strange thing is
> that the *first* occurrence of {{-D}} also has just one value ({{v}}) but
> parsing {{-Dw=1}} does not break over that.
> I can submit a pull request for a bug that demonstrates this, but I have no
> clue how to address it. Also, I don't know if this is actually supposed to
> work. Looking forward to your reaction.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CLI-312) Inconsistent behaviour in key/value pairs (Java property style)
[
https://issues.apache.org/jira/browse/CLI-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17444526#comment-17444526
]
Robert Scholte commented on CLI-312:
Worth mentioning: if there's no separator nor value, then it'll represent the
default value {{true}}
IIRC if there is a separator but no value, it represents an empty string.
> Inconsistent behaviour in key/value pairs (Java property style)
> ---
>
> Key: CLI-312
> URL: https://issues.apache.org/jira/browse/CLI-312
> Project: Commons CLI
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.5
>Reporter: Maarten Mulders
>Priority: Minor
>
> In the Apache Maven project, we used to have an {{Option}} defined like this:
> {code:java}
> Option.builder("D").longOpt("define").hasArg().build()
> {code}
> This allowed our users to define properties using all of these:
> * {{-Dx=1}}
> * {{-Dx}}
> * {{-D x}}
> * {{--define x=1}}
> * {{--define x}}
> Splitting the key/value pairs was something that we did inside Maven
> ([{{MavenCli.java
> #1733}}|https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L1733]
> and [{{MavenCli.java
> #1762}}|https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L1762]).
> In the process of upgrading to Commons CLI 1.5 and moving away from the
> deprecated {{GnuParser}}, we found out that Commons CLI can split argument
> values thanks to the {{valueSeparator}}. We've changed our option declaration
> accordingly:
> {code:java}
> Option.builder("D").longOpt("define").numberOfArgs(2).valueSeparator('=').build()
> );
> {code}
> Unfortunately, this breaks our accepted inputs: {{-Dv -Dw=1 -D x=2 -D y -D
> z=3}} breaks the parsing in Commons CLI:
> {code}
> org.apache.commons.cli.MissingArgumentException: Missing argument for option:
> D
> at
> org.apache.commons.cli.DefaultParser.checkRequiredArgs(DefaultParser.java:231)
> at
> org.apache.commons.cli.DefaultParser.handleOption(DefaultParser.java:394)
> at
> org.apache.commons.cli.DefaultParser.handleShortAndLongOption(DefaultParser.java:467)
> at
> org.apache.commons.cli.DefaultParser.handleToken(DefaultParser.java:542)
> at org.apache.commons.cli.DefaultParser.parse(DefaultParser.java:714)
> at org.apache.commons.cli.DefaultParser.parse(DefaultParser.java:681)
> at org.apache.commons.cli.DefaultParser.parse(DefaultParser.java:662)
> {code}
> From debugging, I've learned that it breaks at the *fifth* occurrence of
> {{-D}} (the one followed by {{z=3}}). It considers the *fourth* occurrence of
> {{-D}} incomplete (having only one value and not two). The strange thing is
> that the *first* occurrence of {{-D}} also has just one value ({{v}}) but
> parsing {{-Dw=1}} does not break over that.
> I can submit a pull request for a bug that demonstrates this, but I have no
> clue how to address it. Also, I don't know if this is actually supposed to
> work. Looking forward to your reaction.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (CLI-269) Introduce CommandLine.Builder
[ https://issues.apache.org/jira/browse/CLI-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed CLI-269. -- Resolution: Fixed Fix Version/s: 1.4 Fixed in [1784363|http://svn.apache.org/viewvc?rev=1784363=rev] > Introduce CommandLine.Builder > - > > Key: CLI-269 > URL: https://issues.apache.org/jira/browse/CLI-269 > Project: Commons CLI > Issue Type: New Feature > Components: Build >Affects Versions: 1.3.1 >Reporter: Robert Scholte > Fix For: 1.4 > > Attachments: commandlinebuilder.patch > > > For Maven there are several places where one can define the commandline > arguments. These should be merged to 1 new commandline, but we need to have > control over the order in which these are merged. > Best solution seems to be to introduce a CommandLineBuilder. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CLI-269) Introduce CommandLine.Builder
[ https://issues.apache.org/jira/browse/CLI-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated CLI-269: --- Summary: Introduce CommandLine.Builder (was: Introduce CommandLineBuilder) > Introduce CommandLine.Builder > - > > Key: CLI-269 > URL: https://issues.apache.org/jira/browse/CLI-269 > Project: Commons CLI > Issue Type: New Feature > Components: Build >Affects Versions: 1.3.1 >Reporter: Robert Scholte > Attachments: commandlinebuilder.patch > > > For Maven there are several places where one can define the commandline > arguments. These should be merged to 1 new commandline, but we need to have > control over the order in which these are merged. > Best solution seems to be to introduce a CommandLineBuilder. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLI-269) Introduce CommandLineBuilder
[ https://issues.apache.org/jira/browse/CLI-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15883600#comment-15883600 ] Robert Scholte commented on CLI-269: Yeah, auto-save formatting, will reduce the noice > Introduce CommandLineBuilder > > > Key: CLI-269 > URL: https://issues.apache.org/jira/browse/CLI-269 > Project: Commons CLI > Issue Type: New Feature > Components: Build >Affects Versions: 1.3.1 >Reporter: Robert Scholte > Attachments: commandlinebuilder.patch > > > For Maven there are several places where one can define the commandline > arguments. These should be merged to 1 new commandline, but we need to have > control over the order in which these are merged. > Best solution seems to be to introduce a CommandLineBuilder. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CLI-269) Introduce CommandLineBuilder
[ https://issues.apache.org/jira/browse/CLI-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated CLI-269: --- Attachment: commandlinebuilder.patch > Introduce CommandLineBuilder > > > Key: CLI-269 > URL: https://issues.apache.org/jira/browse/CLI-269 > Project: Commons CLI > Issue Type: New Feature > Components: Build >Affects Versions: 1.3.1 >Reporter: Robert Scholte > Attachments: commandlinebuilder.patch > > > For Maven there are several places where one can define the commandline > arguments. These should be merged to 1 new commandline, but we need to have > control over the order in which these are merged. > Best solution seems to be to introduce a CommandLineBuilder. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CLI-269) Introduce CommandLineBuilder
Robert Scholte created CLI-269: -- Summary: Introduce CommandLineBuilder Key: CLI-269 URL: https://issues.apache.org/jira/browse/CLI-269 Project: Commons CLI Issue Type: New Feature Components: Build Affects Versions: 1.3.1 Reporter: Robert Scholte For Maven there are several places where one can define the commandline arguments. These should be merged to 1 new commandline, but we need to have control over the order in which these are merged. Best solution seems to be to introduce a CommandLineBuilder. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] Closed: (LANG-425) Sequence(String)Utils
[
https://issues.apache.org/jira/browse/LANG-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed LANG-425.
---
Resolution: Won't Fix
Ok, I'll close it myself.
With java5 this has become less interesting, maybe even useless. There are two
reasons:
- autoboxing (although I don't know if I really like this feature)
- the atomic toolkit (
http://www.j2ee.me/j2se/1.5.0/docs/api/java/util/concurrent/atomic/package-summary.html
)
Sequence(String)Utils
-
Key: LANG-425
URL: https://issues.apache.org/jira/browse/LANG-425
Project: Commons Lang
Issue Type: Wish
Affects Versions: 2.4
Reporter: Robert Scholte
Priority: Trivial
Fix For: 3.0
Don't you think it's kind of strange to have RandomUtils and
RandomStringUtils, but not just the ordinairy SequenceUtils?
I've seen commons-id in the sandbox, but maybe some basics should become part
of commons lang.
Most classes of within this package are stateless/static, or they have a
state within a method (such as StrBuilder). SequenceUtils can only be static,
if it has the startValue.
For example
{code}
SequenceUtils.nextInt(10)
SequenceUtils.nextString(MORE)
SequenceUtils.nextBoolean(true) //ok, this one is stupid but quite clear
SequenceUtils.nextString(C0DE, 0123456789ABCDEF) //next hexadecimal
{code}
any more ideas?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-425) Sequence(String)Utils
[
https://issues.apache.org/jira/browse/LANG-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12727231#action_12727231
]
Robert Scholte commented on LANG-425:
-
After rereading all comments I see I made a terrible mistake. Some of the
methods were based on primitives. For them it's absolutely useless to have
these methods, but for their Object equivalent it is (or was pre java5).
The suggested hexImpl was just an example, you could also think of a sequence
of strings without fowels.
CharSequence is a bit misleading, because there's also a java.lang.CharSequence
which has another goal.
The UnicodeSequence look a bit odd to me: why a builderstrategy here?
Sequence(String)Utils
-
Key: LANG-425
URL: https://issues.apache.org/jira/browse/LANG-425
Project: Commons Lang
Issue Type: Wish
Affects Versions: 2.4
Reporter: Robert Scholte
Priority: Trivial
Fix For: 3.0
Don't you think it's kind of strange to have RandomUtils and
RandomStringUtils, but not just the ordinairy SequenceUtils?
I've seen commons-id in the sandbox, but maybe some basics should become part
of commons lang.
Most classes of within this package are stateless/static, or they have a
state within a method (such as StrBuilder). SequenceUtils can only be static,
if it has the startValue.
For example
{code}
SequenceUtils.nextInt(10)
SequenceUtils.nextString(MORE)
SequenceUtils.nextBoolean(true) //ok, this one is stupid but quite clear
SequenceUtils.nextString(C0DE, 0123456789ABCDEF) //next hexadecimal
{code}
any more ideas?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-340) performance problem with EqualsBuilder.append()
[
https://issues.apache.org/jira/browse/LANG-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12609605#action_12609605
]
Robert Scholte commented on LANG-340:
-
I think I have to agree with Henri. And there's an important difference between
both code-samples:
The EqualsBuilder-implementation first checks the label, followed by the name,
while the self-written one first checks the name.
Normally names would be more unique then labels, so I'm not really surprised
the second implementation is faster.
performance problem with EqualsBuilder.append()
---
Key: LANG-340
URL: https://issues.apache.org/jira/browse/LANG-340
Project: Commons Lang
Issue Type: Improvement
Affects Versions: 2.3
Reporter: Ramil Israfilov
Fix For: 3.0
We are using EqualsBuilder for construction of equals() method in our
javabeans.
For example we have a class:
public class SimpleRecord{
String name;
String label;
...
public boolean equals(Object object) {
return new EqualsBuilder().append(this.label, rhs.label).append(
this.getName(), rhs.getName()).isEquals();
}
So far so good.
But one of our applications uses extensively Stack to push/pop SimpleRecord
bean. And it was working very slow.
After profiling of application we saw that most of the time JVM spent in
equals() method of SimpleRecord. (it is called during peek() which is calling
remove() from Stack)
If we replace EqualsBuilder by following code our application worked 3 times
faster ! Could you make some optimizations ?
if (!(object instanceof SimpleRecord)) {
return false;
}
SimpleRecord rhs = (SimpleRecord) object;
if (this.getName() == null rhs.getName() != null) {
return false;
} else
if (rhs.getName() == null this.getName() != null) {
return false;
} else
if (this.label == null rhs.label != null) {
return false;
} else
if (rhs.label == null this.label != null) {
return false;
} else
if (this.label == null rhs.label == null) {
return this.getName().equals(rhs.getName());
} else
return this.getName().equals(rhs.getName())
this.label.equals(rhs.label);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-447) String case-insensitive comparisons, equals, and hashing
[ https://issues.apache.org/jira/browse/LANG-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12609615#action_12609615 ] Robert Scholte commented on LANG-447: - Sounds like [LANG-316] String case-insensitive comparisons, equals, and hashing Key: LANG-447 URL: https://issues.apache.org/jira/browse/LANG-447 Project: Commons Lang Issue Type: Improvement Reporter: Paul Benedict Fix For: 3.0 A common pattern I have is comparing strings case-insensitive in equals(), but this also means for hashCode() and compareTo() as well. I am looking for null-safe versions of the following: StringUtils.equalsIgnoreCase(s1, s2); // already present StringUtils.compareToIgnoreCase(s1, s2); CompareToBuilder.appendIgnoreCase(s1, s2); HashCodeBuilder.appendIgnoreCase(s1, s2); The last three methods must use the same insensitive algorithm as equalsIgnoreCase(). All four must compare as upper case or lower case, and documented as such. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-443) DateUtils should test with the extremes
[ https://issues.apache.org/jira/browse/LANG-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated LANG-443: Attachment: LANG-443-rs.patch First set of new tests. If DateUtils.ceil() is available, this file must also test this method DateUtils should test with the extremes --- Key: LANG-443 URL: https://issues.apache.org/jira/browse/LANG-443 Project: Commons Lang Issue Type: Task Affects Versions: 2.4 Reporter: Robert Scholte Priority: Minor Fix For: 3.0 Attachments: LANG-443-rs.patch Current testdates are a bit to generic. Especially for truncating, ceiling and rounding you shuold test for the extremes. So for rounding to hours you should test for 0:29 (rounding down); 0:30 (rounding up); 1:00 (no rounding required) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-425) Sequence(String)Utils
[
https://issues.apache.org/jira/browse/LANG-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12605676#action_12605676
]
Robert Scholte commented on LANG-425:
-
Both generics and autoboxing are features of java5, while commons-lang must be
able to compile with java 1.3. But with LangTwo this will become possible.
Of course it's possible to create the classes with these ideas in mind. So I
guess for commons-lang no generic interface yet.
And considering the hasNext()-issue: even that is possible. For instance: when
using Integer.MAX_VALUE together with the IntegerSequence the method wil return
false.
Sequence(String)Utils
-
Key: LANG-425
URL: https://issues.apache.org/jira/browse/LANG-425
Project: Commons Lang
Issue Type: Wish
Affects Versions: 2.4
Reporter: Robert Scholte
Priority: Trivial
Don't you think it's kind of strange to have RandomUtils and
RandomStringUtils, but not just the ordinairy SequenceUtils?
I've seen commons-id in the sandbox, but maybe some basics should become part
of commons lang.
Most classes of within this package are stateless/static, or they have a
state within a method (such as StrBuilder). SequenceUtils can only be static,
if it has the startValue.
For example
{code}
SequenceUtils.nextInt(10)
SequenceUtils.nextString(MORE)
SequenceUtils.nextBoolean(true) //ok, this one is stupid but quite clear
SequenceUtils.nextString(C0DE, 0123456789ABCDEF) //next hexadecimal
{code}
any more ideas?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-434) Add DateUtils.ceiling() method
[ https://issues.apache.org/jira/browse/LANG-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated LANG-434: Attachment: LANG-434-rs.patch issue 440 was committed. Now the tests for this issue work fine. Added both ceil-method and it's tests Add DateUtils.ceiling() method -- Key: LANG-434 URL: https://issues.apache.org/jira/browse/LANG-434 Project: Commons Lang Issue Type: Improvement Affects Versions: 2.4 Reporter: Travis Reeder Fix For: 3.0 Attachments: LANG-434-rs.patch It would be nice to have a DateUtils.ceiling methods which would be the opposite of truncate (which is equivalent to floor) DateUtils.ceiling(Date d, int field); For example, if you had the datetime of 28 Mar 2002 13:45:01.231, if you passed with HOUR, it would return 28 Mar 2002 13:59:59.999. If this was passed with MONTH, it would return 31 Mar 2002 23:59:59.999. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-443) DateUtils should test with the extremes
DateUtils should test with the extremes --- Key: LANG-443 URL: https://issues.apache.org/jira/browse/LANG-443 Project: Commons Lang Issue Type: Task Affects Versions: 2.4 Reporter: Robert Scholte Priority: Minor Fix For: 3.0 Current testdates are a bit to generic. Especially for truncating, ceiling and rounding you shuold test for the extremes. So for rounding to hours you should test for 0:29 (rounding down); 0:30 (rounding up); 1:00 (no rounding required) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-440) DateUtils.round doesn't work correct for Calendar.AM_PM
[
https://issues.apache.org/jira/browse/LANG-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated LANG-440:
Attachment: LANG-440-rs.patch
Added code for correct rounding based on AM_PM and repaired the JUnit-tests
(and their comments)
DateUtils.round doesn't work correct for Calendar.AM_PM
---
Key: LANG-440
URL: https://issues.apache.org/jira/browse/LANG-440
Project: Commons Lang
Issue Type: Bug
Affects Versions: 2.4
Reporter: Robert Scholte
Fix For: 3.0
Attachments: LANG-440-rs.patch
The provided JUnit-tests test with wrong expected values
{code:title= original DateUtilsTest.java}
dateAmPm1 = dateTimeParser.parse(February 3, 2002 01:10:00.000);
dateAmPm2 = dateTimeParser.parse(February 3, 2002 11:10:00.000);
dateAmPm3 = dateTimeParser.parse(February 3, 2002 13:10:00.000);
dateAmPm4 = dateTimeParser.parse(February 3, 2002 19:10:00.000);
assertEquals(truncate ampm-1 failed,
dateTimeParser.parse(February 3, 2002 00:00:00.000),
DateUtils.round(dateAmPm1, Calendar.AM_PM));
assertEquals(truncate ampm-2 failed,
dateTimeParser.parse(February 4, 2002 00:00:00.000),
DateUtils.round(dateAmPm2, Calendar.AM_PM));
assertEquals(truncate ampm-3 failed,
dateTimeParser.parse(February 3, 2002 12:00:00.000),
DateUtils.round(dateAmPm3, Calendar.AM_PM));
assertEquals(truncate ampm-4 failed,
dateTimeParser.parse(February 4, 2002 12:00:00.000),
DateUtils.round(dateAmPm4, Calendar.AM_PM));
{code}
but expected values must be
{code}
dateTimeParser.parse(February 3, 2002 00:00:00.000);
dateTimeParser.parse(February 3, 2002 12:00:00.000);
dateTimeParser.parse(February 3, 2002 12:00:00.000);
dateTimeParser.parse(February 4, 2002 00:00:00.000);
{code}
Also in the junit-comment the word 'truncate' must be replaced with 'round'
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-440) DateUtils.round doesn't work correct for Calendar.AM_PM
[
https://issues.apache.org/jira/browse/LANG-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12601756#action_12601756
]
Robert Scholte commented on LANG-440:
-
Patch is on it's way
DateUtils.round doesn't work correct for Calendar.AM_PM
---
Key: LANG-440
URL: https://issues.apache.org/jira/browse/LANG-440
Project: Commons Lang
Issue Type: Bug
Affects Versions: 2.4
Reporter: Robert Scholte
Fix For: 3.0
The provided JUnit-tests test with wrong expected values
{code:title= original DateUtilsTest.java}
dateAmPm1 = dateTimeParser.parse(February 3, 2002 01:10:00.000);
dateAmPm2 = dateTimeParser.parse(February 3, 2002 11:10:00.000);
dateAmPm3 = dateTimeParser.parse(February 3, 2002 13:10:00.000);
dateAmPm4 = dateTimeParser.parse(February 3, 2002 19:10:00.000);
assertEquals(truncate ampm-1 failed,
dateTimeParser.parse(February 3, 2002 00:00:00.000),
DateUtils.round(dateAmPm1, Calendar.AM_PM));
assertEquals(truncate ampm-2 failed,
dateTimeParser.parse(February 4, 2002 00:00:00.000),
DateUtils.round(dateAmPm2, Calendar.AM_PM));
assertEquals(truncate ampm-3 failed,
dateTimeParser.parse(February 3, 2002 12:00:00.000),
DateUtils.round(dateAmPm3, Calendar.AM_PM));
assertEquals(truncate ampm-4 failed,
dateTimeParser.parse(February 4, 2002 12:00:00.000),
DateUtils.round(dateAmPm4, Calendar.AM_PM));
{code}
but expected values must be
{code}
dateTimeParser.parse(February 3, 2002 00:00:00.000);
dateTimeParser.parse(February 3, 2002 12:00:00.000);
dateTimeParser.parse(February 3, 2002 12:00:00.000);
dateTimeParser.parse(February 4, 2002 00:00:00.000);
{code}
Also in the junit-comment the word 'truncate' must be replaced with 'round'
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-440) DateUtils.round doesn't work correct for Calendar.AM_PM
DateUtils.round doesn't work correct for Calendar.AM_PM
---
Key: LANG-440
URL: https://issues.apache.org/jira/browse/LANG-440
Project: Commons Lang
Issue Type: Bug
Affects Versions: 2.4
Reporter: Robert Scholte
Fix For: 3.0
The provided JUnit-tests test with wrong expected values
{code:title= original DateUtilsTest.java}
dateAmPm1 = dateTimeParser.parse(February 3, 2002 01:10:00.000);
dateAmPm2 = dateTimeParser.parse(February 3, 2002 11:10:00.000);
dateAmPm3 = dateTimeParser.parse(February 3, 2002 13:10:00.000);
dateAmPm4 = dateTimeParser.parse(February 3, 2002 19:10:00.000);
assertEquals(truncate ampm-1 failed,
dateTimeParser.parse(February 3, 2002 00:00:00.000),
DateUtils.round(dateAmPm1, Calendar.AM_PM));
assertEquals(truncate ampm-2 failed,
dateTimeParser.parse(February 4, 2002 00:00:00.000),
DateUtils.round(dateAmPm2, Calendar.AM_PM));
assertEquals(truncate ampm-3 failed,
dateTimeParser.parse(February 3, 2002 12:00:00.000),
DateUtils.round(dateAmPm3, Calendar.AM_PM));
assertEquals(truncate ampm-4 failed,
dateTimeParser.parse(February 4, 2002 12:00:00.000),
DateUtils.round(dateAmPm4, Calendar.AM_PM));
{code}
but expected values must be
{code}
dateTimeParser.parse(February 3, 2002 00:00:00.000);
dateTimeParser.parse(February 3, 2002 12:00:00.000);
dateTimeParser.parse(February 3, 2002 12:00:00.000);
dateTimeParser.parse(February 4, 2002 00:00:00.000);
{code}
Also in the junit-comment the word 'truncate' must be replaced with 'round'
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-434) Add DateUtils.ceiling() method
[
https://issues.apache.org/jira/browse/LANG-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600550#action_12600550
]
Robert Scholte commented on LANG-434:
-
I've started creating a patch and wrote some tests based on the truncate and
round-tests, but I ran into something strange. Watch the following sniplets:
{code:title=DateUtilsTest.java}
protected void setUp() throws Exception {
dateAmPm1 = dateTimeParser.parse(February 3, 2002 01:10:00.000);
dateAmPm2 = dateTimeParser.parse(February 3, 2002 11:10:00.000);
dateAmPm3 = dateTimeParser.parse(February 3, 2002 13:10:00.000);
dateAmPm4 = dateTimeParser.parse(February 3, 2002 19:10:00.000);
}
{code}
and
{code:title=DateUtilsTest.java}
public void testRound() throws Exception {
assertEquals(truncate ampm-1 failed,
dateTimeParser.parse(February 3, 2002 00:00:00.000),
DateUtils.round(dateAmPm1, Calendar.AM_PM));
assertEquals(truncate ampm-2 failed,
dateTimeParser.parse(February 4, 2002 00:00:00.000),
DateUtils.round(dateAmPm2, Calendar.AM_PM));
assertEquals(truncate ampm-3 failed,
dateTimeParser.parse(February 3, 2002 12:00:00.000),
DateUtils.round(dateAmPm3, Calendar.AM_PM));
assertEquals(truncate ampm-4 failed,
dateTimeParser.parse(February 4, 2002 12:00:00.000),
DateUtils.round(dateAmPm4, Calendar.AM_PM));
}
{code}
Minor issue: the comment has to be round instead of truncate
But I'd expected the values round to the nearest noon or midnight. In other
words:
ampm-2 as February 3, 2002 12:00:00.000
ampm-4 as February 4, 2002 00:00:00.000
Could someone explain to me what's going on?
Add DateUtils.ceiling() method
--
Key: LANG-434
URL: https://issues.apache.org/jira/browse/LANG-434
Project: Commons Lang
Issue Type: Improvement
Affects Versions: 2.4
Reporter: Travis Reeder
Fix For: 3.0
It would be nice to have a DateUtils.ceiling methods which would be the
opposite of truncate (which is equivalent to floor)
DateUtils.ceiling(Date d, int field);
For example, if you had the datetime of 28 Mar 2002 13:45:01.231, if you
passed with HOUR, it would return 28 Mar 2002 13:59:59.999. If this was
passed with MONTH, it would return 31 Mar 2002 23:59:59.999.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-434) Add DateUtils.ceiling() method
[
https://issues.apache.org/jira/browse/LANG-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12594537#action_12594537
]
Robert Scholte commented on LANG-434:
-
I've had a look at the source, and it looks to me we need to use the private
method modify since it has a fix for
[http://issues.apache.org/jira/browse/LANG-59], but then it's signature has to
be changed.
{code}
/**
* pInternal calculation method./p
*
* @param val the calendar
* @param field the field constant
* @param round true to round, false to truncate
* @throws ArithmeticException if the year is over 280 million
*/
private static void modify(Calendar val, int field, boolean round)
{code}
Just a suggestion:
{code}
/**
* pInternal calculation method./p
*
* @param val the calendar
* @param field the field constant
* @param round -1 to floor, 0 to round, 1 to ceil
* @throws ArithmeticException if the year is over 280 million
*/
private static void modify(Calendar val, int field, int round)
{code}
Add DateUtils.ceiling() method
--
Key: LANG-434
URL: https://issues.apache.org/jira/browse/LANG-434
Project: Commons Lang
Issue Type: Improvement
Affects Versions: 2.4
Reporter: Travis Reeder
Fix For: 3.0
It would be nice to have a DateUtils.ceiling methods which would be the
opposite of truncate (which is equivalent to floor)
DateUtils.ceiling(Date d, int field);
For example, if you had the datetime of 28 Mar 2002 13:45:01.231, if you
passed with HOUR, it would return 28 Mar 2002 13:59:59.999. If this was
passed with MONTH, it would return 31 Mar 2002 23:59:59.999.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-434) Add DateUtils.ceiling() method
[ https://issues.apache.org/jira/browse/LANG-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12593821#action_12593821 ] Robert Scholte commented on LANG-434: - If you follow java's Math-api, it would be DateUtils.ceil(Date d, int field) and not ceiling. And ceil would give you the next full value, which means you need to add that last millisecond. Following your examples: if you had the datetime of 28 Mar 2002 13:45:01.231, if you passed with HOUR, it would return 28 Mar 2002 14:00:00.000. If this was passed with MONTH, it would return 1 Apr 2002 00:00:00.000. Add DateUtils.ceiling() method -- Key: LANG-434 URL: https://issues.apache.org/jira/browse/LANG-434 Project: Commons Lang Issue Type: Improvement Affects Versions: 2.4 Reporter: Travis Reeder It would be nice to have a DateUtils.ceiling methods which would be the opposite of truncate (which is equivalent to floor) DateUtils.ceiling(Date d, int field); For example, if you had the datetime of 28 Mar 2002 13:45:01.231, if you passed with HOUR, it would return 28 Mar 2002 13:59:59.999. If this was passed with MONTH, it would return 31 Mar 2002 23:59:59.999. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (LANG-425) Sequence(String)Utils
[
https://issues.apache.org/jira/browse/LANG-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12592572#action_12592572
]
rfscholte-getthere edited comment on LANG-425 at 4/27/08 10:56 AM:
---
Oops, my mistake. Some expected results would have been right.
NextInt(10) is actually 11 (a simple ++ would do the trick already), but what
about the object-version. So nextInteger(new Integer(10)) would result in new
Integer(11);
Now the strings:
MORE + 1 = MORF; MORF+1 = MORG MORZ+1= MOSA MOZZ+1 = MPAA;
+1= ? (maybe outOfBounds)
with a second argument you could define the chars to use and it's order.
so: C0DE (C-zero-DE) C0DF C0E0 C0E1 and so on
Maybe an optional step (like for-loops) could be interesting
for Floats and Doubles it's more tricky. These types will always require a step.
was (Author: rfscholte-getthere):
Oops, my mistake. Some expected results would have been right.
NextInt(10) is actually 11 (a simple ++ would do the trick already), but what
about the object-version. So nextInteger(new Integer(10)) would result in new
Integer(11);
Now the strings:
MORE + 1 = MORF; MORF+1 = MORG MORZ+1= MOSA MOZZ+1 = MPAA;
+1= ? (maybe outOfBounds)
with a second argument you could define the chars to use and it's order.
so: C0DE (C-zero-DE) C0DF C0E0 C0D1 and so on
Maybe an optional step (like for-loops) could be interesting
for Floats and Doubles it's more tricky. These types will always require a step.
Sequence(String)Utils
-
Key: LANG-425
URL: https://issues.apache.org/jira/browse/LANG-425
Project: Commons Lang
Issue Type: Wish
Affects Versions: 2.4
Reporter: Robert Scholte
Priority: Trivial
Don't you think it's kind of strange to have RandomUtils and
RandomStringUtils, but not just the ordinairy SequenceUtils?
I've seen commons-id in the sandbox, but maybe some basics should become part
of commons lang.
Most classes of within this package are stateless/static, or they have a
state within a method (such as StrBuilder). SequenceUtils can only be static,
if it has the startValue.
For example
{code}
SequenceUtils.nextInt(10)
SequenceUtils.nextString(MORE)
SequenceUtils.nextBoolean(true) //ok, this one is stupid but quite clear
SequenceUtils.nextString(C0DE, 0123456789ABCDEF) //next hexadecimal
{code}
any more ideas?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-425) Sequence(String)Utils
[
https://issues.apache.org/jira/browse/LANG-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12592666#action_12592666
]
Robert Scholte commented on LANG-425:
-
That was my first idea too, but after having some thoughts I don't think this
would be the right way, or at least not the only one.
The code you suggest is covered by
[commons-id|http://commons.apache.org/sandbox/id/] (a sandbox and 1.0-snapshot
project)
What they do is:
{code} IdentifierGeneratorFactory factory =
IdentifierGeneratorFactory.newInstance();
StringIdentifierGenerator generator = factory.alphanumericGenerator();
String id = generator.nextStringIdentifier();
{code}
But for commons-lang this approach might be a bit overdone.
Maybe both ways must be supported: a memento (statefull)-version and a utils
(stateless)-version.
If you want to loop, use the first option. If you just want the next, use the
second.
For a simple String+1 you shouldn't need to create an object by constructor and
call it's nextString()
Sequence(String)Utils
-
Key: LANG-425
URL: https://issues.apache.org/jira/browse/LANG-425
Project: Commons Lang
Issue Type: Wish
Affects Versions: 2.4
Reporter: Robert Scholte
Priority: Trivial
Don't you think it's kind of strange to have RandomUtils and
RandomStringUtils, but not just the ordinairy SequenceUtils?
I've seen commons-id in the sandbox, but maybe some basics should become part
of commons lang.
Most classes of within this package are stateless/static, or they have a
state within a method (such as StrBuilder). SequenceUtils can only be static,
if it has the startValue.
For example
{code}
SequenceUtils.nextInt(10)
SequenceUtils.nextString(MORE)
SequenceUtils.nextBoolean(true) //ok, this one is stupid but quite clear
SequenceUtils.nextString(C0DE, 0123456789ABCDEF) //next hexadecimal
{code}
any more ideas?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-425) Sequence(String)Utils
[
https://issues.apache.org/jira/browse/LANG-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12592572#action_12592572
]
Robert Scholte commented on LANG-425:
-
Oops, my mistake. Some expected results would have been right.
NextInt(10) is actually 11 (a simple ++ would do the trick already), but what
about the object-version. So nextInteger(new Integer(10)) would result in new
Integer(11);
Now the strings:
MORE + 1 = MORF; MORF+1 = MORG MORZ+1= MOSA MOZZ+1 = MPAA;
+1= ? (maybe outOfBounds)
with a second argument you could define the chars to use and it's order.
so: C0DE (C-zero-DE) C0DF C0E0 C0D1 and so on
Maybe an optional step (like for-loops) could be interesting
for Floats and Doubles it's more tricky. These types will always require a step.
Sequence(String)Utils
-
Key: LANG-425
URL: https://issues.apache.org/jira/browse/LANG-425
Project: Commons Lang
Issue Type: Wish
Affects Versions: 2.4
Reporter: Robert Scholte
Priority: Trivial
Don't you think it's kind of strange to have RandomUtils and
RandomStringUtils, but not just the ordinairy SequenceUtils?
I've seen commons-id in the sandbox, but maybe some basics should become part
of commons lang.
Most classes of within this package are stateless/static, or they have a
state within a method (such as StrBuilder). SequenceUtils can only be static,
if it has the startValue.
For example
{code}
SequenceUtils.nextInt(10)
SequenceUtils.nextString(MORE)
SequenceUtils.nextBoolean(true) //ok, this one is stupid but quite clear
SequenceUtils.nextString(C0DE, 0123456789ABCDEF) //next hexadecimal
{code}
any more ideas?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-427) StringUtils code readability (method acceleration)
[
https://issues.apache.org/jira/browse/LANG-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12591057#action_12591057
]
Robert Scholte commented on LANG-427:
-
I can't see which unittests you've written, so it's hard to make conclusions
yet.
Doesn't it have to do with an optimistic or pessimistic approach? If you're
optimistic and expects the string to be blank your approach is probably faster.
But if you expect the string not to be blank the original version is faster, I
guess. (or should you use isNotBlank() in this case?)
And about the readablility: both implementations are clear enough. But I guess
the speed usualy prio one
StringUtils code readability (method acceleration)
--
Key: LANG-427
URL: https://issues.apache.org/jira/browse/LANG-427
Project: Commons Lang
Issue Type: Improvement
Environment: All systems, all plattforms
Reporter: Torsten
Priority: Trivial
Original Estimate: 0.08h
Remaining Estimate: 0.08h
First of all i hope you will let me stay alive :) because this is not a
critical error or even a bug. My proposal will not help to make the method
run twice as fast, but I think this would make the code easier to read, test
and to maintain. I tested both methods with Strings of length 1 to 1 and
with growing size of the Strings, the second method got actual faster and it
*never* was slower.
This method is from the framework:
{code:title=StringUtils.java|borderStyle=solid}
public static boolean isBlank(String str) {
int strLen;
if (str == null || (strLen = str.length()) == 0) {
return true;
}
for (int i = 0; i strLen; i++) {
if ((Character.isWhitespace(str.charAt(i)) == false)) {
return false;
}
}
return true;
}
{code}
I think this method would have the same result:
{code:borderStyle=solid}
public static final boolean isBlank(String str) {
return str == null || str.trim().length() == 0;
}
{code}
Greetings from Germany
Torsten
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (LANG-427) StringUtils code readability (method acceleration)
[
https://issues.apache.org/jira/browse/LANG-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12591057#action_12591057
]
rfscholte-getthere edited comment on LANG-427 at 4/21/08 2:03 PM:
--
I can't see which unittests you've written, so it's hard to make conclusions
yet.
Doesn't it have to do with an optimistic or pessimistic approach? If you're
optimistic and expects the string to be blank your approach is probably faster.
But if you expect the string not to be blank the original version is faster, I
guess. (or should you use isNotBlank() in this case?)
And about the readablility: both implementations are clear enough. But I guess
the speed is usualy prio one
was (Author: rfscholte-getthere):
I can't see which unittests you've written, so it's hard to make
conclusions yet.
Doesn't it have to do with an optimistic or pessimistic approach? If you're
optimistic and expects the string to be blank your approach is probably faster.
But if you expect the string not to be blank the original version is faster, I
guess. (or should you use isNotBlank() in this case?)
And about the readablility: both implementations are clear enough. But I guess
the speed usualy prio one
StringUtils code readability (method acceleration)
--
Key: LANG-427
URL: https://issues.apache.org/jira/browse/LANG-427
Project: Commons Lang
Issue Type: Improvement
Environment: All systems, all plattforms
Reporter: Torsten
Priority: Trivial
Original Estimate: 0.08h
Remaining Estimate: 0.08h
First of all i hope you will let me stay alive :) because this is not a
critical error or even a bug. My proposal will not help to make the method
run twice as fast, but I think this would make the code easier to read, test
and to maintain. I tested both methods with Strings of length 1 to 1 and
with growing size of the Strings, the second method got actual faster and it
*never* was slower.
This method is from the framework:
{code:title=StringUtils.java|borderStyle=solid}
public static boolean isBlank(String str) {
int strLen;
if (str == null || (strLen = str.length()) == 0) {
return true;
}
for (int i = 0; i strLen; i++) {
if ((Character.isWhitespace(str.charAt(i)) == false)) {
return false;
}
}
return true;
}
{code}
I think this method would have the same result:
{code:borderStyle=solid}
public static final boolean isBlank(String str) {
return str == null || str.trim().length() == 0;
}
{code}
Greetings from Germany
Torsten
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-422) StrBuilder appendSeparator with defaultIfEmpty
[
https://issues.apache.org/jira/browse/LANG-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587071#action_12587071
]
Robert Scholte commented on LANG-422:
-
No worries, I'll write this stuff.
StrBuilder appendSeparator with defaultIfEmpty
--
Key: LANG-422
URL: https://issues.apache.org/jira/browse/LANG-422
Project: Commons Lang
Issue Type: Improvement
Affects Versions: 2.4
Reporter: Robert Scholte
Priority: Minor
Fix For: 3.0
If would like to suggest the following method for the StrBuilder class:
*appendSeparator(String separator, String defaultIfEmpty)*
it's usage is very handy for building queries (a much more I guess)
{code}
StrBuilder whereClause = new StrBuilder();
if(searchCommand.priority != null) {
whereClause.appendSeparator( and, where);
whereClause.append( priority = ?)
}
if(searchCommand.component != null) {
whereClause.appendSeparator( and, where);
whereClause.append( component = ?)
}
// if(!whereClause.isEmpty()) {
// selectClause.append( where)
// selectClause.append(whereClause)
//}
selectClause.append(whereClause)
{code}
this can be done for every queryClause (eliminating all isEmpty-checks), but
there are usefull usecases
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (LANG-422) StrBuilder appendSeparator with defaultIfEmpty
[
https://issues.apache.org/jira/browse/LANG-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587071#action_12587071
]
rfscholte-getthere edited comment on LANG-422 at 4/9/08 2:41 AM:
-
No worries, I'll write this stuff.
But which of the appendSeparators should support defaultIfEmpty?
I guess only the (String) and (Char) -methods, not the looping-ones.
was (Author: rfscholte-getthere):
No worries, I'll write this stuff.
StrBuilder appendSeparator with defaultIfEmpty
--
Key: LANG-422
URL: https://issues.apache.org/jira/browse/LANG-422
Project: Commons Lang
Issue Type: Improvement
Affects Versions: 2.4
Reporter: Robert Scholte
Priority: Minor
Fix For: 3.0
If would like to suggest the following method for the StrBuilder class:
*appendSeparator(String separator, String defaultIfEmpty)*
it's usage is very handy for building queries (a much more I guess)
{code}
StrBuilder whereClause = new StrBuilder();
if(searchCommand.priority != null) {
whereClause.appendSeparator( and, where);
whereClause.append( priority = ?)
}
if(searchCommand.component != null) {
whereClause.appendSeparator( and, where);
whereClause.append( component = ?)
}
// if(!whereClause.isEmpty()) {
// selectClause.append( where)
// selectClause.append(whereClause)
//}
selectClause.append(whereClause)
{code}
this can be done for every queryClause (eliminating all isEmpty-checks), but
there are usefull usecases
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-422) StrBuilder appendSeparator with defaultIfEmpty
StrBuilder appendSeparator with defaultIfEmpty
--
Key: LANG-422
URL: https://issues.apache.org/jira/browse/LANG-422
Project: Commons Lang
Issue Type: Improvement
Affects Versions: 2.4
Reporter: Robert Scholte
Priority: Minor
Fix For: 3.0
If would like to suggest the following method for the StrBuilder class:
*appendSeparator(String separator, String defaultIfEmpty)*
it's usage is very handy for building queries (a much more I guess)
{code}
StrBuilder whereClause = new StrBuilder();
if(searchCommand.priority != null) {
whereClause.appendSeparator( and, where);
whereClause.append( priority = ?)
}
if(searchCommand.component != null) {
whereClause.appendSeparator( and, where);
whereClause.append( component = ?)
}
// if(!whereClause.isEmpty()) {
// selectClause.append( where)
// selectClause.append(whereClause)
//}
selectClause.append(whereClause)
{code}
this can be done for every queryClause (eliminating all isEmpty-checks), but
there are usefull usecases
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-417) ClassUtils: method for turning FQN into resource path
[
https://issues.apache.org/jira/browse/LANG-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577134#action_12577134
]
Robert Scholte commented on LANG-417:
-
Maybe this requires a PackageUtils, because it's got nothing to do with the
class itself but just with it's package.
I think the most logic method would be
public static String toResourcePath(Package p)...
public static String toResourcePath(Package p, String fqName) ...
this has to be combined with:
public static Package getPackage(Class clazz)
and yes, this would mean a new class: Package.
although it would require 2 steps, the methods would be very clear. IMHO the
suggested methodnames are just too ugly.
ClassUtils: method for turning FQN into resource path
-
Key: LANG-417
URL: https://issues.apache.org/jira/browse/LANG-417
Project: Commons Lang
Issue Type: New Feature
Reporter: Paul Benedict
Fix For: 2.4
I commonly need a FQ path to a resource within the same location as a class
file. I recommend the addition of this method:
public String getPackageResourcePath(Class clazz, String resourceName)
StringBuffer buf = new StringBuffer();
buf.append(ClassUtils.getPackageName(getClass()).replace('.', '/'));
buf.append(/);
buf.append(resourceName);
return buf.toString();
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-379) Calculating A date fragment in any time-unit
[
https://issues.apache.org/jira/browse/LANG-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564688#action_12564688
]
Robert Scholte commented on LANG-379:
-
Henri,
thanks alot
Calculating A date fragment in any time-unit
Key: LANG-379
URL: https://issues.apache.org/jira/browse/LANG-379
Project: Commons Lang
Issue Type: New Feature
Affects Versions: 2.3
Reporter: Robert Scholte
Priority: Minor
Fix For: 2.4
Attachments: DateUtils.patch, DateUtils_2.patch,
DateUtilsFragmentTest.java, LANG-379.patch
These DateUtils-features can make it possible to calculate a date-part in any
time-unit. For example: the number of minutes of this year, the number of
seconds of today, etc.
I've started with some coding, and if there's enough interest we can make it
more solid.
public static long getFragmentInSeconds(Date date, int fragment) {
return getFragment(date, fragment, Calendar.SECOND);
}
public static long getFragmentInMinutes(Date date, int fragment) {
return getFragment(date, fragment, Calendar.MINUTE);
}
public static long getFragmentInHours(Date date, int fragment) {
return getFragment(date, fragment, Calendar.HOUR_OF_DAY);
}
public static long getFragmentInDays(Date date, int fragment) {
return getFragment(date, fragment, Calendar.DAY_OF_YEAR);
}
public static long getFragmentInSeconds(Calendar calendar, int
fragment) {
return getFragment(calendar, fragment, Calendar.SECOND);
}
public static long getFragmentInMinutes(Calendar calendar, int
fragment) {
return getFragment(calendar, fragment, Calendar.MINUTE);
}
public static long getFragmentInHours(Calendar calendar, int fragment) {
return getFragment(calendar, fragment, Calendar.HOUR_OF_DAY);
}
public static long getFragmentInDays(Calendar calendar, int fragment) {
return getFragment(calendar, fragment, Calendar.DAY_OF_YEAR);
}
private static long getFragment(Date date, int fragment, int unit) {
Calendar calendar = Calendar.getInstance();
calendar.setTime(date);
return getFragment(calendar, fragment, unit);
}
private static long getFragment(Calendar calendar, int fragment, int
unit) {
long millisPerUnit = getMillisPerFragment(unit);
long result = 0;
switch (fragment) {
case Calendar.YEAR:
result += (calendar.get(Calendar.DAY_OF_YEAR) *
MILLIS_PER_DAY) / millisPerUnit;
case Calendar.MONTH:
result += (calendar.get(Calendar.DAY_OF_MONTH) *
MILLIS_PER_DAY) / millisPerUnit;
case Calendar.DAY_OF_YEAR:
case Calendar.DATE:
result += (calendar.get(Calendar.HOUR_OF_DAY) *
MILLIS_PER_HOUR) / millisPerUnit;
case Calendar.HOUR_OF_DAY:
result += (calendar.get(Calendar.MINUTE) *
MILLIS_PER_MINUTE) / millisPerUnit;
case Calendar.MINUTE:
result += (calendar.get(Calendar.SECOND) *
MILLIS_PER_SECOND) / millisPerUnit;
case Calendar.SECOND:
result += (calendar.get(Calendar.MILLISECOND) * 1) /
millisPerUnit;
}
return result;
}
private static long getMillisPerFragment(int fragment) {
long result = Long.MAX_VALUE;
switch (fragment) {
case Calendar.DAY_OF_YEAR:
case Calendar.DATE:
result = MILLIS_PER_DAY;
break;
case Calendar.HOUR_OF_DAY:
result = MILLIS_PER_HOUR;
break;
case Calendar.MINUTE:
result = MILLIS_PER_MINUTE;
break;
case Calendar.SECOND:
result = MILLIS_PER_SECOND;
break;
case Calendar.MILLISECOND:
result = 1;
break;
}
return result;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-379) Calculating A date fragment in any time-unit
[
https://issues.apache.org/jira/browse/LANG-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated LANG-379:
Attachment: DateUtils_2.patch
I've added some examples per method in their javadoc-block. Hopefully we're now
close enough...
Calculating A date fragment in any time-unit
Key: LANG-379
URL: https://issues.apache.org/jira/browse/LANG-379
Project: Commons Lang
Issue Type: New Feature
Affects Versions: 2.3
Reporter: Robert Scholte
Priority: Minor
Fix For: 2.4
Attachments: DateUtils.patch, DateUtils_2.patch,
DateUtilsFragmentTest.java
These DateUtils-features can make it possible to calculate a date-part in any
time-unit. For example: the number of minutes of this year, the number of
seconds of today, etc.
I've started with some coding, and if there's enough interest we can make it
more solid.
public static long getFragmentInSeconds(Date date, int fragment) {
return getFragment(date, fragment, Calendar.SECOND);
}
public static long getFragmentInMinutes(Date date, int fragment) {
return getFragment(date, fragment, Calendar.MINUTE);
}
public static long getFragmentInHours(Date date, int fragment) {
return getFragment(date, fragment, Calendar.HOUR_OF_DAY);
}
public static long getFragmentInDays(Date date, int fragment) {
return getFragment(date, fragment, Calendar.DAY_OF_YEAR);
}
public static long getFragmentInSeconds(Calendar calendar, int
fragment) {
return getFragment(calendar, fragment, Calendar.SECOND);
}
public static long getFragmentInMinutes(Calendar calendar, int
fragment) {
return getFragment(calendar, fragment, Calendar.MINUTE);
}
public static long getFragmentInHours(Calendar calendar, int fragment) {
return getFragment(calendar, fragment, Calendar.HOUR_OF_DAY);
}
public static long getFragmentInDays(Calendar calendar, int fragment) {
return getFragment(calendar, fragment, Calendar.DAY_OF_YEAR);
}
private static long getFragment(Date date, int fragment, int unit) {
Calendar calendar = Calendar.getInstance();
calendar.setTime(date);
return getFragment(calendar, fragment, unit);
}
private static long getFragment(Calendar calendar, int fragment, int
unit) {
long millisPerUnit = getMillisPerFragment(unit);
long result = 0;
switch (fragment) {
case Calendar.YEAR:
result += (calendar.get(Calendar.DAY_OF_YEAR) *
MILLIS_PER_DAY) / millisPerUnit;
case Calendar.MONTH:
result += (calendar.get(Calendar.DAY_OF_MONTH) *
MILLIS_PER_DAY) / millisPerUnit;
case Calendar.DAY_OF_YEAR:
case Calendar.DATE:
result += (calendar.get(Calendar.HOUR_OF_DAY) *
MILLIS_PER_HOUR) / millisPerUnit;
case Calendar.HOUR_OF_DAY:
result += (calendar.get(Calendar.MINUTE) *
MILLIS_PER_MINUTE) / millisPerUnit;
case Calendar.MINUTE:
result += (calendar.get(Calendar.SECOND) *
MILLIS_PER_SECOND) / millisPerUnit;
case Calendar.SECOND:
result += (calendar.get(Calendar.MILLISECOND) * 1) /
millisPerUnit;
}
return result;
}
private static long getMillisPerFragment(int fragment) {
long result = Long.MAX_VALUE;
switch (fragment) {
case Calendar.DAY_OF_YEAR:
case Calendar.DATE:
result = MILLIS_PER_DAY;
break;
case Calendar.HOUR_OF_DAY:
result = MILLIS_PER_HOUR;
break;
case Calendar.MINUTE:
result = MILLIS_PER_MINUTE;
break;
case Calendar.SECOND:
result = MILLIS_PER_SECOND;
break;
case Calendar.MILLISECOND:
result = 1;
break;
}
return result;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-379) Calculating A date fragment in any time-unit
[
https://issues.apache.org/jira/browse/LANG-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated LANG-379:
Attachment: DateUtilsFragmentTest.java
separate junit-test for all DateUtils' fragmentmethods
Calculating A date fragment in any time-unit
Key: LANG-379
URL: https://issues.apache.org/jira/browse/LANG-379
Project: Commons Lang
Issue Type: New Feature
Affects Versions: 2.3
Reporter: Robert Scholte
Priority: Minor
Fix For: 2.4
Attachments: DateUtils-fragments.patch, DateUtilsFragmentTest.java
These DateUtils-features can make it possible to calculate a date-part in any
time-unit. For example: the number of minutes of this year, the number of
seconds of today, etc.
I've started with some coding, and if there's enough interest we can make it
more solid.
public static long getFragmentInSeconds(Date date, int fragment) {
return getFragment(date, fragment, Calendar.SECOND);
}
public static long getFragmentInMinutes(Date date, int fragment) {
return getFragment(date, fragment, Calendar.MINUTE);
}
public static long getFragmentInHours(Date date, int fragment) {
return getFragment(date, fragment, Calendar.HOUR_OF_DAY);
}
public static long getFragmentInDays(Date date, int fragment) {
return getFragment(date, fragment, Calendar.DAY_OF_YEAR);
}
public static long getFragmentInSeconds(Calendar calendar, int
fragment) {
return getFragment(calendar, fragment, Calendar.SECOND);
}
public static long getFragmentInMinutes(Calendar calendar, int
fragment) {
return getFragment(calendar, fragment, Calendar.MINUTE);
}
public static long getFragmentInHours(Calendar calendar, int fragment) {
return getFragment(calendar, fragment, Calendar.HOUR_OF_DAY);
}
public static long getFragmentInDays(Calendar calendar, int fragment) {
return getFragment(calendar, fragment, Calendar.DAY_OF_YEAR);
}
private static long getFragment(Date date, int fragment, int unit) {
Calendar calendar = Calendar.getInstance();
calendar.setTime(date);
return getFragment(calendar, fragment, unit);
}
private static long getFragment(Calendar calendar, int fragment, int
unit) {
long millisPerUnit = getMillisPerFragment(unit);
long result = 0;
switch (fragment) {
case Calendar.YEAR:
result += (calendar.get(Calendar.DAY_OF_YEAR) *
MILLIS_PER_DAY) / millisPerUnit;
case Calendar.MONTH:
result += (calendar.get(Calendar.DAY_OF_MONTH) *
MILLIS_PER_DAY) / millisPerUnit;
case Calendar.DAY_OF_YEAR:
case Calendar.DATE:
result += (calendar.get(Calendar.HOUR_OF_DAY) *
MILLIS_PER_HOUR) / millisPerUnit;
case Calendar.HOUR_OF_DAY:
result += (calendar.get(Calendar.MINUTE) *
MILLIS_PER_MINUTE) / millisPerUnit;
case Calendar.MINUTE:
result += (calendar.get(Calendar.SECOND) *
MILLIS_PER_SECOND) / millisPerUnit;
case Calendar.SECOND:
result += (calendar.get(Calendar.MILLISECOND) * 1) /
millisPerUnit;
}
return result;
}
private static long getMillisPerFragment(int fragment) {
long result = Long.MAX_VALUE;
switch (fragment) {
case Calendar.DAY_OF_YEAR:
case Calendar.DATE:
result = MILLIS_PER_DAY;
break;
case Calendar.HOUR_OF_DAY:
result = MILLIS_PER_HOUR;
break;
case Calendar.MINUTE:
result = MILLIS_PER_MINUTE;
break;
case Calendar.SECOND:
result = MILLIS_PER_SECOND;
break;
case Calendar.MILLISECOND:
result = 1;
break;
}
return result;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-379) Calculating A date fragment in any time-unit
[
https://issues.apache.org/jira/browse/LANG-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated LANG-379:
Attachment: DateUtils.patch
Complete path for DateUtils containing all fragment-methods
Calculating A date fragment in any time-unit
Key: LANG-379
URL: https://issues.apache.org/jira/browse/LANG-379
Project: Commons Lang
Issue Type: New Feature
Affects Versions: 2.3
Reporter: Robert Scholte
Priority: Minor
Fix For: 2.4
Attachments: DateUtils.patch, DateUtilsFragmentTest.java
These DateUtils-features can make it possible to calculate a date-part in any
time-unit. For example: the number of minutes of this year, the number of
seconds of today, etc.
I've started with some coding, and if there's enough interest we can make it
more solid.
public static long getFragmentInSeconds(Date date, int fragment) {
return getFragment(date, fragment, Calendar.SECOND);
}
public static long getFragmentInMinutes(Date date, int fragment) {
return getFragment(date, fragment, Calendar.MINUTE);
}
public static long getFragmentInHours(Date date, int fragment) {
return getFragment(date, fragment, Calendar.HOUR_OF_DAY);
}
public static long getFragmentInDays(Date date, int fragment) {
return getFragment(date, fragment, Calendar.DAY_OF_YEAR);
}
public static long getFragmentInSeconds(Calendar calendar, int
fragment) {
return getFragment(calendar, fragment, Calendar.SECOND);
}
public static long getFragmentInMinutes(Calendar calendar, int
fragment) {
return getFragment(calendar, fragment, Calendar.MINUTE);
}
public static long getFragmentInHours(Calendar calendar, int fragment) {
return getFragment(calendar, fragment, Calendar.HOUR_OF_DAY);
}
public static long getFragmentInDays(Calendar calendar, int fragment) {
return getFragment(calendar, fragment, Calendar.DAY_OF_YEAR);
}
private static long getFragment(Date date, int fragment, int unit) {
Calendar calendar = Calendar.getInstance();
calendar.setTime(date);
return getFragment(calendar, fragment, unit);
}
private static long getFragment(Calendar calendar, int fragment, int
unit) {
long millisPerUnit = getMillisPerFragment(unit);
long result = 0;
switch (fragment) {
case Calendar.YEAR:
result += (calendar.get(Calendar.DAY_OF_YEAR) *
MILLIS_PER_DAY) / millisPerUnit;
case Calendar.MONTH:
result += (calendar.get(Calendar.DAY_OF_MONTH) *
MILLIS_PER_DAY) / millisPerUnit;
case Calendar.DAY_OF_YEAR:
case Calendar.DATE:
result += (calendar.get(Calendar.HOUR_OF_DAY) *
MILLIS_PER_HOUR) / millisPerUnit;
case Calendar.HOUR_OF_DAY:
result += (calendar.get(Calendar.MINUTE) *
MILLIS_PER_MINUTE) / millisPerUnit;
case Calendar.MINUTE:
result += (calendar.get(Calendar.SECOND) *
MILLIS_PER_SECOND) / millisPerUnit;
case Calendar.SECOND:
result += (calendar.get(Calendar.MILLISECOND) * 1) /
millisPerUnit;
}
return result;
}
private static long getMillisPerFragment(int fragment) {
long result = Long.MAX_VALUE;
switch (fragment) {
case Calendar.DAY_OF_YEAR:
case Calendar.DATE:
result = MILLIS_PER_DAY;
break;
case Calendar.HOUR_OF_DAY:
result = MILLIS_PER_HOUR;
break;
case Calendar.MINUTE:
result = MILLIS_PER_MINUTE;
break;
case Calendar.SECOND:
result = MILLIS_PER_SECOND;
break;
case Calendar.MILLISECOND:
result = 1;
break;
}
return result;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-379) Calculating A date fragment in any time-unit
[
https://issues.apache.org/jira/browse/LANG-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated LANG-379:
Attachment: (was: DateUtils-fragments.patch)
Calculating A date fragment in any time-unit
Key: LANG-379
URL: https://issues.apache.org/jira/browse/LANG-379
Project: Commons Lang
Issue Type: New Feature
Affects Versions: 2.3
Reporter: Robert Scholte
Priority: Minor
Fix For: 2.4
Attachments: DateUtils.patch, DateUtilsFragmentTest.java
These DateUtils-features can make it possible to calculate a date-part in any
time-unit. For example: the number of minutes of this year, the number of
seconds of today, etc.
I've started with some coding, and if there's enough interest we can make it
more solid.
public static long getFragmentInSeconds(Date date, int fragment) {
return getFragment(date, fragment, Calendar.SECOND);
}
public static long getFragmentInMinutes(Date date, int fragment) {
return getFragment(date, fragment, Calendar.MINUTE);
}
public static long getFragmentInHours(Date date, int fragment) {
return getFragment(date, fragment, Calendar.HOUR_OF_DAY);
}
public static long getFragmentInDays(Date date, int fragment) {
return getFragment(date, fragment, Calendar.DAY_OF_YEAR);
}
public static long getFragmentInSeconds(Calendar calendar, int
fragment) {
return getFragment(calendar, fragment, Calendar.SECOND);
}
public static long getFragmentInMinutes(Calendar calendar, int
fragment) {
return getFragment(calendar, fragment, Calendar.MINUTE);
}
public static long getFragmentInHours(Calendar calendar, int fragment) {
return getFragment(calendar, fragment, Calendar.HOUR_OF_DAY);
}
public static long getFragmentInDays(Calendar calendar, int fragment) {
return getFragment(calendar, fragment, Calendar.DAY_OF_YEAR);
}
private static long getFragment(Date date, int fragment, int unit) {
Calendar calendar = Calendar.getInstance();
calendar.setTime(date);
return getFragment(calendar, fragment, unit);
}
private static long getFragment(Calendar calendar, int fragment, int
unit) {
long millisPerUnit = getMillisPerFragment(unit);
long result = 0;
switch (fragment) {
case Calendar.YEAR:
result += (calendar.get(Calendar.DAY_OF_YEAR) *
MILLIS_PER_DAY) / millisPerUnit;
case Calendar.MONTH:
result += (calendar.get(Calendar.DAY_OF_MONTH) *
MILLIS_PER_DAY) / millisPerUnit;
case Calendar.DAY_OF_YEAR:
case Calendar.DATE:
result += (calendar.get(Calendar.HOUR_OF_DAY) *
MILLIS_PER_HOUR) / millisPerUnit;
case Calendar.HOUR_OF_DAY:
result += (calendar.get(Calendar.MINUTE) *
MILLIS_PER_MINUTE) / millisPerUnit;
case Calendar.MINUTE:
result += (calendar.get(Calendar.SECOND) *
MILLIS_PER_SECOND) / millisPerUnit;
case Calendar.SECOND:
result += (calendar.get(Calendar.MILLISECOND) * 1) /
millisPerUnit;
}
return result;
}
private static long getMillisPerFragment(int fragment) {
long result = Long.MAX_VALUE;
switch (fragment) {
case Calendar.DAY_OF_YEAR:
case Calendar.DATE:
result = MILLIS_PER_DAY;
break;
case Calendar.HOUR_OF_DAY:
result = MILLIS_PER_HOUR;
break;
case Calendar.MINUTE:
result = MILLIS_PER_MINUTE;
break;
case Calendar.SECOND:
result = MILLIS_PER_SECOND;
break;
case Calendar.MILLISECOND:
result = 1;
break;
}
return result;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (LANG-379) Calculating A date fragment in any time-unit
[
https://issues.apache.org/jira/browse/LANG-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12562073#action_12562073
]
rfscholte-getthere edited comment on LANG-379 at 1/24/08 6:08 AM:
--
Complete path for DateUtils containing all fragment-methods
Most important changes
a lot of javadoc containing description of usage
added getFragmentInMilliseconds() ( How could I've forgotten this one...)
removed Calendar.WEEK_OF_* as valid fragment, since this is a weird way of usage
was (Author: rfscholte-getthere):
Complete path for DateUtils containing all fragment-methods
Calculating A date fragment in any time-unit
Key: LANG-379
URL: https://issues.apache.org/jira/browse/LANG-379
Project: Commons Lang
Issue Type: New Feature
Affects Versions: 2.3
Reporter: Robert Scholte
Priority: Minor
Fix For: 2.4
Attachments: DateUtils.patch, DateUtilsFragmentTest.java
These DateUtils-features can make it possible to calculate a date-part in any
time-unit. For example: the number of minutes of this year, the number of
seconds of today, etc.
I've started with some coding, and if there's enough interest we can make it
more solid.
public static long getFragmentInSeconds(Date date, int fragment) {
return getFragment(date, fragment, Calendar.SECOND);
}
public static long getFragmentInMinutes(Date date, int fragment) {
return getFragment(date, fragment, Calendar.MINUTE);
}
public static long getFragmentInHours(Date date, int fragment) {
return getFragment(date, fragment, Calendar.HOUR_OF_DAY);
}
public static long getFragmentInDays(Date date, int fragment) {
return getFragment(date, fragment, Calendar.DAY_OF_YEAR);
}
public static long getFragmentInSeconds(Calendar calendar, int
fragment) {
return getFragment(calendar, fragment, Calendar.SECOND);
}
public static long getFragmentInMinutes(Calendar calendar, int
fragment) {
return getFragment(calendar, fragment, Calendar.MINUTE);
}
public static long getFragmentInHours(Calendar calendar, int fragment) {
return getFragment(calendar, fragment, Calendar.HOUR_OF_DAY);
}
public static long getFragmentInDays(Calendar calendar, int fragment) {
return getFragment(calendar, fragment, Calendar.DAY_OF_YEAR);
}
private static long getFragment(Date date, int fragment, int unit) {
Calendar calendar = Calendar.getInstance();
calendar.setTime(date);
return getFragment(calendar, fragment, unit);
}
private static long getFragment(Calendar calendar, int fragment, int
unit) {
long millisPerUnit = getMillisPerFragment(unit);
long result = 0;
switch (fragment) {
case Calendar.YEAR:
result += (calendar.get(Calendar.DAY_OF_YEAR) *
MILLIS_PER_DAY) / millisPerUnit;
case Calendar.MONTH:
result += (calendar.get(Calendar.DAY_OF_MONTH) *
MILLIS_PER_DAY) / millisPerUnit;
case Calendar.DAY_OF_YEAR:
case Calendar.DATE:
result += (calendar.get(Calendar.HOUR_OF_DAY) *
MILLIS_PER_HOUR) / millisPerUnit;
case Calendar.HOUR_OF_DAY:
result += (calendar.get(Calendar.MINUTE) *
MILLIS_PER_MINUTE) / millisPerUnit;
case Calendar.MINUTE:
result += (calendar.get(Calendar.SECOND) *
MILLIS_PER_SECOND) / millisPerUnit;
case Calendar.SECOND:
result += (calendar.get(Calendar.MILLISECOND) * 1) /
millisPerUnit;
}
return result;
}
private static long getMillisPerFragment(int fragment) {
long result = Long.MAX_VALUE;
switch (fragment) {
case Calendar.DAY_OF_YEAR:
case Calendar.DATE:
result = MILLIS_PER_DAY;
break;
case Calendar.HOUR_OF_DAY:
result = MILLIS_PER_HOUR;
break;
case Calendar.MINUTE:
result = MILLIS_PER_MINUTE;
break;
case Calendar.SECOND:
result = MILLIS_PER_SECOND;
break;
case Calendar.MILLISECOND:
result = 1;
break;
}
return result;
}
--
This message is
[jira] Commented: (LANG-379) Calculating A date fragment in any time-unit
[
https://issues.apache.org/jira/browse/LANG-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560450#action_12560450
]
Robert Scholte commented on LANG-379:
-
Maybe the problem of LANG-400 isn't clear enough for me, but it looks like
you're searching for something like
cal1 = DateUtils.round(cal1, Calendar.DATE);
cal2 = DateUtils.round(cal2, Calendar.DATE);
returning 1 of the following statements...
cal1.after(cal2);
cal1.before(cal2);
if this doens't match with the problem try to give an example.
I agree, both have to do with some kind of date-transformation. But it seems to
me LANG-400 requires ignoring fields bottom-up, where this issue ignores field
top-down.
Calculating A date fragment in any time-unit
Key: LANG-379
URL: https://issues.apache.org/jira/browse/LANG-379
Project: Commons Lang
Issue Type: New Feature
Affects Versions: 2.3
Reporter: Robert Scholte
Priority: Minor
Fix For: 2.4
Attachments: DateUtils-fragments.patch, DateUtilsFragmentTest.java
These DateUtils-features can make it possible to calculate a date-part in any
time-unit. For example: the number of minutes of this year, the number of
seconds of today, etc.
I've started with some coding, and if there's enough interest we can make it
more solid.
public static long getFragmentInSeconds(Date date, int fragment) {
return getFragment(date, fragment, Calendar.SECOND);
}
public static long getFragmentInMinutes(Date date, int fragment) {
return getFragment(date, fragment, Calendar.MINUTE);
}
public static long getFragmentInHours(Date date, int fragment) {
return getFragment(date, fragment, Calendar.HOUR_OF_DAY);
}
public static long getFragmentInDays(Date date, int fragment) {
return getFragment(date, fragment, Calendar.DAY_OF_YEAR);
}
public static long getFragmentInSeconds(Calendar calendar, int
fragment) {
return getFragment(calendar, fragment, Calendar.SECOND);
}
public static long getFragmentInMinutes(Calendar calendar, int
fragment) {
return getFragment(calendar, fragment, Calendar.MINUTE);
}
public static long getFragmentInHours(Calendar calendar, int fragment) {
return getFragment(calendar, fragment, Calendar.HOUR_OF_DAY);
}
public static long getFragmentInDays(Calendar calendar, int fragment) {
return getFragment(calendar, fragment, Calendar.DAY_OF_YEAR);
}
private static long getFragment(Date date, int fragment, int unit) {
Calendar calendar = Calendar.getInstance();
calendar.setTime(date);
return getFragment(calendar, fragment, unit);
}
private static long getFragment(Calendar calendar, int fragment, int
unit) {
long millisPerUnit = getMillisPerFragment(unit);
long result = 0;
switch (fragment) {
case Calendar.YEAR:
result += (calendar.get(Calendar.DAY_OF_YEAR) *
MILLIS_PER_DAY) / millisPerUnit;
case Calendar.MONTH:
result += (calendar.get(Calendar.DAY_OF_MONTH) *
MILLIS_PER_DAY) / millisPerUnit;
case Calendar.DAY_OF_YEAR:
case Calendar.DATE:
result += (calendar.get(Calendar.HOUR_OF_DAY) *
MILLIS_PER_HOUR) / millisPerUnit;
case Calendar.HOUR_OF_DAY:
result += (calendar.get(Calendar.MINUTE) *
MILLIS_PER_MINUTE) / millisPerUnit;
case Calendar.MINUTE:
result += (calendar.get(Calendar.SECOND) *
MILLIS_PER_SECOND) / millisPerUnit;
case Calendar.SECOND:
result += (calendar.get(Calendar.MILLISECOND) * 1) /
millisPerUnit;
}
return result;
}
private static long getMillisPerFragment(int fragment) {
long result = Long.MAX_VALUE;
switch (fragment) {
case Calendar.DAY_OF_YEAR:
case Calendar.DATE:
result = MILLIS_PER_DAY;
break;
case Calendar.HOUR_OF_DAY:
result = MILLIS_PER_HOUR;
break;
case Calendar.MINUTE:
result = MILLIS_PER_MINUTE;
break;
case Calendar.SECOND:
result = MILLIS_PER_SECOND;
break;
case Calendar.MILLISECOND:
result = 1;
[jira] Commented: (LANG-379) Calculating A date fragment in any time-unit
[
https://issues.apache.org/jira/browse/LANG-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560409#action_12560409
]
Robert Scholte commented on LANG-379:
-
I've already started working on your requests. There are enough tests to write,
so it'll take some time to complete proper tests. Is there some deadline or
timeframe within it should be submitted with the next release in mind?
Calculating A date fragment in any time-unit
Key: LANG-379
URL: https://issues.apache.org/jira/browse/LANG-379
Project: Commons Lang
Issue Type: New Feature
Affects Versions: 2.3
Reporter: Robert Scholte
Priority: Minor
Fix For: 2.4
Attachments: DateUtils-fragments.patch, DateUtilsFragmentTest.java
These DateUtils-features can make it possible to calculate a date-part in any
time-unit. For example: the number of minutes of this year, the number of
seconds of today, etc.
I've started with some coding, and if there's enough interest we can make it
more solid.
public static long getFragmentInSeconds(Date date, int fragment) {
return getFragment(date, fragment, Calendar.SECOND);
}
public static long getFragmentInMinutes(Date date, int fragment) {
return getFragment(date, fragment, Calendar.MINUTE);
}
public static long getFragmentInHours(Date date, int fragment) {
return getFragment(date, fragment, Calendar.HOUR_OF_DAY);
}
public static long getFragmentInDays(Date date, int fragment) {
return getFragment(date, fragment, Calendar.DAY_OF_YEAR);
}
public static long getFragmentInSeconds(Calendar calendar, int
fragment) {
return getFragment(calendar, fragment, Calendar.SECOND);
}
public static long getFragmentInMinutes(Calendar calendar, int
fragment) {
return getFragment(calendar, fragment, Calendar.MINUTE);
}
public static long getFragmentInHours(Calendar calendar, int fragment) {
return getFragment(calendar, fragment, Calendar.HOUR_OF_DAY);
}
public static long getFragmentInDays(Calendar calendar, int fragment) {
return getFragment(calendar, fragment, Calendar.DAY_OF_YEAR);
}
private static long getFragment(Date date, int fragment, int unit) {
Calendar calendar = Calendar.getInstance();
calendar.setTime(date);
return getFragment(calendar, fragment, unit);
}
private static long getFragment(Calendar calendar, int fragment, int
unit) {
long millisPerUnit = getMillisPerFragment(unit);
long result = 0;
switch (fragment) {
case Calendar.YEAR:
result += (calendar.get(Calendar.DAY_OF_YEAR) *
MILLIS_PER_DAY) / millisPerUnit;
case Calendar.MONTH:
result += (calendar.get(Calendar.DAY_OF_MONTH) *
MILLIS_PER_DAY) / millisPerUnit;
case Calendar.DAY_OF_YEAR:
case Calendar.DATE:
result += (calendar.get(Calendar.HOUR_OF_DAY) *
MILLIS_PER_HOUR) / millisPerUnit;
case Calendar.HOUR_OF_DAY:
result += (calendar.get(Calendar.MINUTE) *
MILLIS_PER_MINUTE) / millisPerUnit;
case Calendar.MINUTE:
result += (calendar.get(Calendar.SECOND) *
MILLIS_PER_SECOND) / millisPerUnit;
case Calendar.SECOND:
result += (calendar.get(Calendar.MILLISECOND) * 1) /
millisPerUnit;
}
return result;
}
private static long getMillisPerFragment(int fragment) {
long result = Long.MAX_VALUE;
switch (fragment) {
case Calendar.DAY_OF_YEAR:
case Calendar.DATE:
result = MILLIS_PER_DAY;
break;
case Calendar.HOUR_OF_DAY:
result = MILLIS_PER_HOUR;
break;
case Calendar.MINUTE:
result = MILLIS_PER_MINUTE;
break;
case Calendar.SECOND:
result = MILLIS_PER_SECOND;
break;
case Calendar.MILLISECOND:
result = 1;
break;
}
return result;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-379) Calculating A date fragment in any time-unit
[
https://issues.apache.org/jira/browse/LANG-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12557643#action_12557643
]
Robert Scholte commented on LANG-379:
-
Examples can be provided
And for the Why-part: I've come with a couple of reasons. One of the
applications I've worked with used events over some period every day. The way
this is stored was a startdate, an enddate plus the starttime and endtime in
seconds. I was looking for a DateUtils.round, but then the other way around, by
ingoring year, months, etc. Since this was part of the core, I saw developers
reinventing the proper calculation, often resulting in the wrong solution the
first time. So I introduced these methods.
With this in mind I thought it could be interesting to make the unit variable.
And after that the unit.
You can think of a reverse version counting down the days till the next year or
month.
As I mentioned: The most interesting reason I think for including this, is
because it's the opposite of DateUtils.round
Calculating A date fragment in any time-unit
Key: LANG-379
URL: https://issues.apache.org/jira/browse/LANG-379
Project: Commons Lang
Issue Type: New Feature
Affects Versions: 2.3
Reporter: Robert Scholte
Priority: Minor
Fix For: 2.4
Attachments: DateUtils-fragments.patch, DateUtilsFragmentTest.java
These DateUtils-features can make it possible to calculate a date-part in any
time-unit. For example: the number of minutes of this year, the number of
seconds of today, etc.
I've started with some coding, and if there's enough interest we can make it
more solid.
public static long getFragmentInSeconds(Date date, int fragment) {
return getFragment(date, fragment, Calendar.SECOND);
}
public static long getFragmentInMinutes(Date date, int fragment) {
return getFragment(date, fragment, Calendar.MINUTE);
}
public static long getFragmentInHours(Date date, int fragment) {
return getFragment(date, fragment, Calendar.HOUR_OF_DAY);
}
public static long getFragmentInDays(Date date, int fragment) {
return getFragment(date, fragment, Calendar.DAY_OF_YEAR);
}
public static long getFragmentInSeconds(Calendar calendar, int
fragment) {
return getFragment(calendar, fragment, Calendar.SECOND);
}
public static long getFragmentInMinutes(Calendar calendar, int
fragment) {
return getFragment(calendar, fragment, Calendar.MINUTE);
}
public static long getFragmentInHours(Calendar calendar, int fragment) {
return getFragment(calendar, fragment, Calendar.HOUR_OF_DAY);
}
public static long getFragmentInDays(Calendar calendar, int fragment) {
return getFragment(calendar, fragment, Calendar.DAY_OF_YEAR);
}
private static long getFragment(Date date, int fragment, int unit) {
Calendar calendar = Calendar.getInstance();
calendar.setTime(date);
return getFragment(calendar, fragment, unit);
}
private static long getFragment(Calendar calendar, int fragment, int
unit) {
long millisPerUnit = getMillisPerFragment(unit);
long result = 0;
switch (fragment) {
case Calendar.YEAR:
result += (calendar.get(Calendar.DAY_OF_YEAR) *
MILLIS_PER_DAY) / millisPerUnit;
case Calendar.MONTH:
result += (calendar.get(Calendar.DAY_OF_MONTH) *
MILLIS_PER_DAY) / millisPerUnit;
case Calendar.DAY_OF_YEAR:
case Calendar.DATE:
result += (calendar.get(Calendar.HOUR_OF_DAY) *
MILLIS_PER_HOUR) / millisPerUnit;
case Calendar.HOUR_OF_DAY:
result += (calendar.get(Calendar.MINUTE) *
MILLIS_PER_MINUTE) / millisPerUnit;
case Calendar.MINUTE:
result += (calendar.get(Calendar.SECOND) *
MILLIS_PER_SECOND) / millisPerUnit;
case Calendar.SECOND:
result += (calendar.get(Calendar.MILLISECOND) * 1) /
millisPerUnit;
}
return result;
}
private static long getMillisPerFragment(int fragment) {
long result = Long.MAX_VALUE;
switch (fragment) {
case Calendar.DAY_OF_YEAR:
case Calendar.DATE:
result = MILLIS_PER_DAY;
break;
case Calendar.HOUR_OF_DAY:
result = MILLIS_PER_HOUR;
break;
[jira] Commented: (LANG-379) Calculating A date fragment in any time-unit
[
https://issues.apache.org/jira/browse/LANG-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12557224#action_12557224
]
Robert Scholte commented on LANG-379:
-
I guess Calendar.ERA is a bit too much, because it would mean starting from
year 0 (whatever that may be)
There are two (switch)-blocks required: the first one to bring the fragment
back to days (millis per day is the largest available value for calculations,
since millis per month is not constant). In the second block we can keep
calculating, if the unit is smaller then a day. And we can check if the
fragment was valid
I agree on working with Calendars above Dates, but since most DateUtils methods
use Date and if a Calendar is used in a method there's always a Date-equivalent
method, I thought it would be nice do the same here.
Calculating A date fragment in any time-unit
Key: LANG-379
URL: https://issues.apache.org/jira/browse/LANG-379
Project: Commons Lang
Issue Type: New Feature
Affects Versions: 2.3
Reporter: Robert Scholte
Priority: Minor
Fix For: 2.4
Attachments: DateUtils-fragments.patch, DateUtilsFragmentTest.java
These DateUtils-features can make it possible to calculate a date-part in any
time-unit. For example: the number of minutes of this year, the number of
seconds of today, etc.
I've started with some coding, and if there's enough interest we can make it
more solid.
public static long getFragmentInSeconds(Date date, int fragment) {
return getFragment(date, fragment, Calendar.SECOND);
}
public static long getFragmentInMinutes(Date date, int fragment) {
return getFragment(date, fragment, Calendar.MINUTE);
}
public static long getFragmentInHours(Date date, int fragment) {
return getFragment(date, fragment, Calendar.HOUR_OF_DAY);
}
public static long getFragmentInDays(Date date, int fragment) {
return getFragment(date, fragment, Calendar.DAY_OF_YEAR);
}
public static long getFragmentInSeconds(Calendar calendar, int
fragment) {
return getFragment(calendar, fragment, Calendar.SECOND);
}
public static long getFragmentInMinutes(Calendar calendar, int
fragment) {
return getFragment(calendar, fragment, Calendar.MINUTE);
}
public static long getFragmentInHours(Calendar calendar, int fragment) {
return getFragment(calendar, fragment, Calendar.HOUR_OF_DAY);
}
public static long getFragmentInDays(Calendar calendar, int fragment) {
return getFragment(calendar, fragment, Calendar.DAY_OF_YEAR);
}
private static long getFragment(Date date, int fragment, int unit) {
Calendar calendar = Calendar.getInstance();
calendar.setTime(date);
return getFragment(calendar, fragment, unit);
}
private static long getFragment(Calendar calendar, int fragment, int
unit) {
long millisPerUnit = getMillisPerFragment(unit);
long result = 0;
switch (fragment) {
case Calendar.YEAR:
result += (calendar.get(Calendar.DAY_OF_YEAR) *
MILLIS_PER_DAY) / millisPerUnit;
case Calendar.MONTH:
result += (calendar.get(Calendar.DAY_OF_MONTH) *
MILLIS_PER_DAY) / millisPerUnit;
case Calendar.DAY_OF_YEAR:
case Calendar.DATE:
result += (calendar.get(Calendar.HOUR_OF_DAY) *
MILLIS_PER_HOUR) / millisPerUnit;
case Calendar.HOUR_OF_DAY:
result += (calendar.get(Calendar.MINUTE) *
MILLIS_PER_MINUTE) / millisPerUnit;
case Calendar.MINUTE:
result += (calendar.get(Calendar.SECOND) *
MILLIS_PER_SECOND) / millisPerUnit;
case Calendar.SECOND:
result += (calendar.get(Calendar.MILLISECOND) * 1) /
millisPerUnit;
}
return result;
}
private static long getMillisPerFragment(int fragment) {
long result = Long.MAX_VALUE;
switch (fragment) {
case Calendar.DAY_OF_YEAR:
case Calendar.DATE:
result = MILLIS_PER_DAY;
break;
case Calendar.HOUR_OF_DAY:
result = MILLIS_PER_HOUR;
break;
case Calendar.MINUTE:
result = MILLIS_PER_MINUTE;
break;
case Calendar.SECOND:
result = MILLIS_PER_SECOND;
[jira] Updated: (LANG-379) Calculating A date fragment in any time-unit
[
https://issues.apache.org/jira/browse/LANG-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated LANG-379:
Attachment: DateUtils-fragments.patch
As suggested by Paul Benedict, a patch which includes throwing an
IllegalArgumentException for both date/calendar is null and unsupported
fragments
Calculating A date fragment in any time-unit
Key: LANG-379
URL: https://issues.apache.org/jira/browse/LANG-379
Project: Commons Lang
Issue Type: New Feature
Affects Versions: 2.4
Reporter: Robert Scholte
Priority: Minor
Attachments: DateUtils-fragments.patch, DateUtilsFragmentTest.java
These DateUtils-features can make it possible to calculate a date-part in any
time-unit. For example: the number of minutes of this year, the number of
seconds of today, etc.
I've started with some coding, and if there's enough interest we can make it
more solid.
public static long getFragmentInSeconds(Date date, int fragment) {
return getFragment(date, fragment, Calendar.SECOND);
}
public static long getFragmentInMinutes(Date date, int fragment) {
return getFragment(date, fragment, Calendar.MINUTE);
}
public static long getFragmentInHours(Date date, int fragment) {
return getFragment(date, fragment, Calendar.HOUR_OF_DAY);
}
public static long getFragmentInDays(Date date, int fragment) {
return getFragment(date, fragment, Calendar.DAY_OF_YEAR);
}
public static long getFragmentInSeconds(Calendar calendar, int
fragment) {
return getFragment(calendar, fragment, Calendar.SECOND);
}
public static long getFragmentInMinutes(Calendar calendar, int
fragment) {
return getFragment(calendar, fragment, Calendar.MINUTE);
}
public static long getFragmentInHours(Calendar calendar, int fragment) {
return getFragment(calendar, fragment, Calendar.HOUR_OF_DAY);
}
public static long getFragmentInDays(Calendar calendar, int fragment) {
return getFragment(calendar, fragment, Calendar.DAY_OF_YEAR);
}
private static long getFragment(Date date, int fragment, int unit) {
Calendar calendar = Calendar.getInstance();
calendar.setTime(date);
return getFragment(calendar, fragment, unit);
}
private static long getFragment(Calendar calendar, int fragment, int
unit) {
long millisPerUnit = getMillisPerFragment(unit);
long result = 0;
switch (fragment) {
case Calendar.YEAR:
result += (calendar.get(Calendar.DAY_OF_YEAR) *
MILLIS_PER_DAY) / millisPerUnit;
case Calendar.MONTH:
result += (calendar.get(Calendar.DAY_OF_MONTH) *
MILLIS_PER_DAY) / millisPerUnit;
case Calendar.DAY_OF_YEAR:
case Calendar.DATE:
result += (calendar.get(Calendar.HOUR_OF_DAY) *
MILLIS_PER_HOUR) / millisPerUnit;
case Calendar.HOUR_OF_DAY:
result += (calendar.get(Calendar.MINUTE) *
MILLIS_PER_MINUTE) / millisPerUnit;
case Calendar.MINUTE:
result += (calendar.get(Calendar.SECOND) *
MILLIS_PER_SECOND) / millisPerUnit;
case Calendar.SECOND:
result += (calendar.get(Calendar.MILLISECOND) * 1) /
millisPerUnit;
}
return result;
}
private static long getMillisPerFragment(int fragment) {
long result = Long.MAX_VALUE;
switch (fragment) {
case Calendar.DAY_OF_YEAR:
case Calendar.DATE:
result = MILLIS_PER_DAY;
break;
case Calendar.HOUR_OF_DAY:
result = MILLIS_PER_HOUR;
break;
case Calendar.MINUTE:
result = MILLIS_PER_MINUTE;
break;
case Calendar.SECOND:
result = MILLIS_PER_SECOND;
break;
case Calendar.MILLISECOND:
result = 1;
break;
}
return result;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-379) Calculating A date fragment in any time-unit
Calculating A date fragment in any time-unit
Key: LANG-379
URL: https://issues.apache.org/jira/browse/LANG-379
Project: Commons Lang
Issue Type: New Feature
Affects Versions: 2.4
Reporter: Robert Scholte
Priority: Minor
These DateUtils-features can make it possible to calculate a date-part in any
time-unit. For example: the number of minutes of this year, the number of
seconds of today, etc.
I've started with some coding, and if there's enough interest we can make it
more solid.
public static long getFragmentInSeconds(Date date, int fragment) {
return getFragment(date, fragment, Calendar.SECOND);
}
public static long getFragmentInMinutes(Date date, int fragment) {
return getFragment(date, fragment, Calendar.MINUTE);
}
public static long getFragmentInHours(Date date, int fragment) {
return getFragment(date, fragment, Calendar.HOUR_OF_DAY);
}
public static long getFragmentInDays(Date date, int fragment) {
return getFragment(date, fragment, Calendar.DAY_OF_YEAR);
}
public static long getFragmentInSeconds(Calendar calendar, int
fragment) {
return getFragment(calendar, fragment, Calendar.SECOND);
}
public static long getFragmentInMinutes(Calendar calendar, int
fragment) {
return getFragment(calendar, fragment, Calendar.MINUTE);
}
public static long getFragmentInHours(Calendar calendar, int fragment) {
return getFragment(calendar, fragment, Calendar.HOUR_OF_DAY);
}
public static long getFragmentInDays(Calendar calendar, int fragment) {
return getFragment(calendar, fragment, Calendar.DAY_OF_YEAR);
}
private static long getFragment(Date date, int fragment, int unit) {
Calendar calendar = Calendar.getInstance();
calendar.setTime(date);
return getFragment(calendar, fragment, unit);
}
private static long getFragment(Calendar calendar, int fragment, int
unit) {
long millisPerUnit = getMillisPerFragment(unit);
long result = 0;
switch (fragment) {
case Calendar.YEAR:
result += (calendar.get(Calendar.DAY_OF_YEAR) *
MILLIS_PER_DAY) / millisPerUnit;
case Calendar.MONTH:
result += (calendar.get(Calendar.DAY_OF_MONTH) *
MILLIS_PER_DAY) / millisPerUnit;
case Calendar.DAY_OF_YEAR:
case Calendar.DATE:
result += (calendar.get(Calendar.HOUR_OF_DAY) *
MILLIS_PER_HOUR) / millisPerUnit;
case Calendar.HOUR_OF_DAY:
result += (calendar.get(Calendar.MINUTE) *
MILLIS_PER_MINUTE) / millisPerUnit;
case Calendar.MINUTE:
result += (calendar.get(Calendar.SECOND) *
MILLIS_PER_SECOND) / millisPerUnit;
case Calendar.SECOND:
result += (calendar.get(Calendar.MILLISECOND) * 1) /
millisPerUnit;
}
return result;
}
private static long getMillisPerFragment(int fragment) {
long result = Long.MAX_VALUE;
switch (fragment) {
case Calendar.DAY_OF_YEAR:
case Calendar.DATE:
result = MILLIS_PER_DAY;
break;
case Calendar.HOUR_OF_DAY:
result = MILLIS_PER_HOUR;
break;
case Calendar.MINUTE:
result = MILLIS_PER_MINUTE;
break;
case Calendar.SECOND:
result = MILLIS_PER_SECOND;
break;
case Calendar.MILLISECOND:
result = 1;
break;
}
return result;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-379) Calculating A date fragment in any time-unit
[
https://issues.apache.org/jira/browse/LANG-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546780
]
Robert Scholte commented on LANG-379:
-
There are still some small issues to solve. One of them is proper exception
handling. This includes UnsupportedFragmentException (or other logic Exception)
and IllegalArgumentException if date is null. Another exception must be caught
when the fragment is smaller then the unit (or should it return 0?) Like I
said: still same enhancements required here.
Calculating A date fragment in any time-unit
Key: LANG-379
URL: https://issues.apache.org/jira/browse/LANG-379
Project: Commons Lang
Issue Type: New Feature
Affects Versions: 2.4
Reporter: Robert Scholte
Priority: Minor
Attachments: DateUtilsFragmentTest.java
These DateUtils-features can make it possible to calculate a date-part in any
time-unit. For example: the number of minutes of this year, the number of
seconds of today, etc.
I've started with some coding, and if there's enough interest we can make it
more solid.
public static long getFragmentInSeconds(Date date, int fragment) {
return getFragment(date, fragment, Calendar.SECOND);
}
public static long getFragmentInMinutes(Date date, int fragment) {
return getFragment(date, fragment, Calendar.MINUTE);
}
public static long getFragmentInHours(Date date, int fragment) {
return getFragment(date, fragment, Calendar.HOUR_OF_DAY);
}
public static long getFragmentInDays(Date date, int fragment) {
return getFragment(date, fragment, Calendar.DAY_OF_YEAR);
}
public static long getFragmentInSeconds(Calendar calendar, int
fragment) {
return getFragment(calendar, fragment, Calendar.SECOND);
}
public static long getFragmentInMinutes(Calendar calendar, int
fragment) {
return getFragment(calendar, fragment, Calendar.MINUTE);
}
public static long getFragmentInHours(Calendar calendar, int fragment) {
return getFragment(calendar, fragment, Calendar.HOUR_OF_DAY);
}
public static long getFragmentInDays(Calendar calendar, int fragment) {
return getFragment(calendar, fragment, Calendar.DAY_OF_YEAR);
}
private static long getFragment(Date date, int fragment, int unit) {
Calendar calendar = Calendar.getInstance();
calendar.setTime(date);
return getFragment(calendar, fragment, unit);
}
private static long getFragment(Calendar calendar, int fragment, int
unit) {
long millisPerUnit = getMillisPerFragment(unit);
long result = 0;
switch (fragment) {
case Calendar.YEAR:
result += (calendar.get(Calendar.DAY_OF_YEAR) *
MILLIS_PER_DAY) / millisPerUnit;
case Calendar.MONTH:
result += (calendar.get(Calendar.DAY_OF_MONTH) *
MILLIS_PER_DAY) / millisPerUnit;
case Calendar.DAY_OF_YEAR:
case Calendar.DATE:
result += (calendar.get(Calendar.HOUR_OF_DAY) *
MILLIS_PER_HOUR) / millisPerUnit;
case Calendar.HOUR_OF_DAY:
result += (calendar.get(Calendar.MINUTE) *
MILLIS_PER_MINUTE) / millisPerUnit;
case Calendar.MINUTE:
result += (calendar.get(Calendar.SECOND) *
MILLIS_PER_SECOND) / millisPerUnit;
case Calendar.SECOND:
result += (calendar.get(Calendar.MILLISECOND) * 1) /
millisPerUnit;
}
return result;
}
private static long getMillisPerFragment(int fragment) {
long result = Long.MAX_VALUE;
switch (fragment) {
case Calendar.DAY_OF_YEAR:
case Calendar.DATE:
result = MILLIS_PER_DAY;
break;
case Calendar.HOUR_OF_DAY:
result = MILLIS_PER_HOUR;
break;
case Calendar.MINUTE:
result = MILLIS_PER_MINUTE;
break;
case Calendar.SECOND:
result = MILLIS_PER_SECOND;
break;
case Calendar.MILLISECOND:
result = 1;
break;
}
return result;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
