You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Robert Scholte (JIRA)" <ji...@apache.org> on 2008/01/10 17:15:34 UTC

[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-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.