[
https://issues.apache.org/jira/browse/LANG-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557643#action_12557643
]
rfscholte-getthere edited comment on LANG-379 at 1/10/08 8:13 AM:
--------------------------------------------------------------
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
And since Calendar.get() always the value compared to it's parent returns
(seconds of minute, hour of day, and so on) there's extra (solid) calculation
required to get the right result
was (Author: rfscholte-getthere):
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;
> 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.
