[url=http://www.javaworld.com/jw-12-2000/jw-1229-dates.html]Calculating Java dates: Take the time to learn how to create and use dates[/url]
[url=http://www.javaworld.com/javaworld/jw-03-2001/jw-0330-time.html]Working in Java time: Learn the basics of calculating elapsed time in Java[/url]
[url=http://www.javaalmanac.com/egs/java.text/FormatDate.html]Formatting a Date Using a Custom Format[/url]
[url=http://www.javaalmanac.com/egs/java.text/ParseDate.html]Parsing a Date Using a Custom Format[/url]
> I'm not thinking Calendar's going to be a lot of help
> here.
Not sure if I understand you. Did you say that because it is a abstract class? I meant for the OP to use the concrete implementation, of course (being the GregorianCalendar which is mentioned in your second reference).
> > I'm not thinking Calendar's going to be a lot of
> help
> > here.
>
> Not sure if I understand you. Did you say that
> because it is a abstract class? I meant for the OP to
> use the concrete implementation, of course (being the
> GregorianCalendar which is mentioned in your second
> reference).
No, I meant in general. Of course, my head might just be stuffed with sawdust and rat droppings. Now that I think about it, doens't dubwai's most excellent elapsed days algorithm use Calendar? I guess that could be adapted for elapsed minutes.
If we ignore leap seconds though, shouldn't a simple millis delta / 60,000 be sufficient?
> ...
> No, I meant in general. Of course, my head might
> just be stuffed with sawdust and rat droppings. Now
> that I think about it, doens't dubwai's most
> excellent elapsed days algorithm use Calendar? I
> guess that could be adapted for elapsed minutes.
If you're talking about the one that works for "modern" dates, then the answer is yes.
> If we ignore leap seconds though, shouldn't a simple
> millis delta / 60,000 be sufficient?
That was my thought as well.
> > If we ignore leap seconds though, shouldn't a
> simple
> > millis delta / 60,000 be sufficient?
>
> That was my thought as well.
In which case how does Calendar help? I assume he's either starting with a Date or a String, which would then be SimpleDateFormat.parsed into a Date. Either way, no Calendar.
> > ...
> > No, I meant in general. Of course, my head might
> > just be stuffed with sawdust and rat droppings.
> Now
> > that I think about it, doens't dubwai's most
> > excellent elapsed days algorithm use Calendar? I
> > guess that could be adapted for elapsed minutes.
>
> If you're talking about the one that works for
> "modern" dates, then the answer is yes.
I've only seen one, but yeah, I guess that's it.
> In which case how does Calendar help? I assume he's
> either starting with a Date or a String, which would
> then be SimpleDateFormat.parsed into a Date. Either
> way, no Calendar.
Ah, ok, I understand your point. I did not take the parsing of date(s) into account.
Looks like I have rat-droppings in my head. I'm off: it's way past my bed time anyway.
G'night.
> Disagreeing with jverd is risky bussiness,
Hardly. Don't confuse verbosity with knowledge or authority. :-)
> but in my
> opinion, if you are going to create a "TimeInterval"
> class, you better use GregorianCalendar straight
> away. Especially if you are messing with dates before
> the introduction of Gregorian time. In the name of
> generality..
Well, as mentioned above, if we're doing minutes and don't care about leap seconds, there's no reason to bring a Calendar into it. Date + arithmetic (and possibly SimpleDateFormat) will give us all that we need.
For a more general case, yes, a GregorianCalendar and dubwai's algorithm is a good way to go.
> [url=http://www.javaworld.com/javaworld/jw-03-2001/jw-0330-time.html?page=1]Working in Java time: Learn the
> basics of calculating elapsed time in Java[/url]
This already helped me a lot, thanks a lot!
I am using the following code to get the current time:
private Date timeAtStartDate = new Date(System.currentTimeMillis());
private SimpleDateFormat timeFormat = new SimpleDateFormat("Hmm");
private String timeAtStartString = timeFormat.format(timeAtStartDate);
The example from JavaWorld (see link above, page 2) uses GregorianCalendar, e.g.:
GregorianCalendar lunarLanding = new GregorianCalendar(1969, Calendar.JULY, 20, 16, 17);
It's not necessary for me to calculate with days, months or even years. Hours and minutes are sufficient :) I don't know how I can get the current time in the GregorianCalendar format so that I can work with the example given at JavaWorld...
> I don't know how I can get the current
> time in the GregorianCalendar formatCalendar now = new GregorianCalendar();
It isn't ridiculously difficult to find that in the API documentation. Please have a look at it before asking such questions.
Oh, seems I was a little distracted by the long introductory example in the java.util.GregorianCalendar API. I am sorry!
Edit: I changed my code and I am now doing the following; first I retrieve the time when the application starts:
private GregorianCalendar timeAtStart = new GregorianCalendar();
int hour24AtStart = timeAtStart.get(Calendar.HOUR_OF_DAY);
int minAtStart = timeAtStart.get(Calendar.MINUTE);
Then I wrote a method with which I calculate the elapsed time:
private String getElapsedTime() {
GregorianCalendar timeNow = new GregorianCalendar();
long diffMillis = timeNow.getTimeInMillis() - timeAtStart.getTimeInMillis();
long diffSecs = diffMillis / 1000;
long diffMins = diffMillis / (60 * 1000);
return (diffMins+":"+diffSecs);
}
I found an example at http://www.exampledepot.com/egs/java.util/CompDates.html; the problem is, that the seconds are counted endlessly - can I change this somehow so that they are being counted only up to 60 seconds and start then new at zero?