• Post Reply Bookmark Topic Watch Topic
  • New Topic

Calendar API  RSS feed

 
Varadhan Sesharaman
Ranch Hand
Posts: 30
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi everyone,

Here is my doubt how can get dates that are in between two given dates using Calendar API.

eg: Dates between 12/05/2012 and 20/05/2012.

How can i implement it through calendar.

Thanks,
Varadhan.s
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16057
88
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Class Calendar has an add() method that you can use to add for example one day to a Calendar. Start by making a Calendar that it set to the start date, then keep adding a day in a loop until you reach the end date.
 
Stanley Mungai
Ranch Hand
Posts: 155
Java Netbeans IDE Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can simply get the difference between the two date as integers like:

 
Campbell Ritchie
Marshal
Posts: 56529
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That last method is slightly inaccurate because it does not take account of leap seconds. It also has incorrect types, and won’t compile because those getTime calls probably return long, not ints.
 
Stanley Mungai
Ranch Hand
Posts: 155
Java Netbeans IDE Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
does not take account of leap seconds.

The use of Gregorian calendar would Quickly sort that.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:That last method is slightly inaccurate because it does not take account of leap seconds.

Actually, that shouldn't be a problem, unless Varadhan was unlucky enough to actually run the method on a leap second - and even then, I doubt whether he could do anything about it.
It also has incorrect types, and won’t compile because those getTime calls probably return long, not ints.

That I will grant you.

@Varadhan: Given the phrasing of your question, I'd go with Jesper's suggestion; but you might want to double check that some nasty person hasn't given you dates that produce more "interim" dates than there are in the Christian calendar.

Winston
 
Campbell Ritchie
Marshal
Posts: 56529
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I did say slightly inaccurate. If you remember that leap seconds only ever occur on 30th June or 31st December, you can conclude that the date range suggested will be free from leap seconds.
What happens if you run it from 12:00:01 Monday to 12:00:00 Tuesday? Rather than having 86400000 milliseconds’ gap, you hve 86399000. And the division will confidently give a result of 0!
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A bigger problem is not leap seconds (does Java even pick those up?) but daylight saving time - summer time for you Brits. If the dates in question cross a DST boundary which occur twice a year, the difference will be off by one hour, plus or minus depending on when the dates are. This will give you an off-by-one-day error about half the time. Oops.

But, there's a simple fix for both leap seconds and DST: Do the division in floating point, and round.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:...What happens if you run it from 12:00:01 Monday to 12:00:00 Tuesday? Rather than having 86400000 milliseconds’ gap, you hve 86399000. And the division will confidently give a result of 0!

Hate to say, but you're wrong there. While the system timer (as presented by System.nanoTime()) will almost certainly include leap seconds, the system clock (as presented by System.currentTimeMillis()) won't. What is possible is for it to return the same value for two consecutive seconds, or (less likely, and has never happened yet) skip a second, but the offset that it returns is always based on an amortized 86,400-second day.

Mike's point is worth noting; however, a simpler remedy (in my opinion) is to use GMT-based dates to do the calculation. It may be slower, but it is self-documenting.

Winston
 
Campbell Ritchie
Marshal
Posts: 56529
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Agree that turning everything to GMT will work.
What I meant about 12:00:01 was that you are using a 23 hour 59 minute 59 second period; if you do integer division by 24 hours you get 0. And how do we know we are using the same clock time for both days? I think leap seconds will give you a 24 hour 0 minutes 0seconds day, which integer division will turn into 1 day.
And as MS pointed out, that sort of thing will happen in March when the clocks go forward; noon 24th March to noon 25th March this year was 23 hours, so integer division will return 0 days.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:What I meant about 12:00:01 was that you are using a 23 hour 59 minute 59 second period; if you do integer division by 24 hours you get 0. And how do we know we are using the same clock time for both days? I think leap seconds will give you a 24 hour 0 minutes 0seconds day, which integer division will turn into 1 day.

Hmmm. Well firstly, Varadhan's question was about dates, not times - and furthermore, dates provided as Strings - so I think it's far more likely that the type of Calendar would make the most difference (I have no idea how dates are written in the Islamic calendar, but I do know that they involve a day, month and year).

Leap seconds won't be involved because neither the system clock nor any Calendar class that I know of registers them; so you, as a user, simply won't know that they occurred.

Winston

[EDIT] @Varadhan: Another thing you might want to do is look at Joda Time. It has all sorts of useful classes for this kind of stuff (I believe Interval is probably the place to start), and most of them are fully interchangeable with Java Dates. It also has fully implemented chronologies for Christian, Islamic, Bhuddist and even Coptic calendars.
 
Campbell Ritchie
Marshal
Posts: 56529
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I keep forgetting about Yoda time. Never tried it, but there are so many deficiencies in the standard date and time API that we need something else.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:I keep forgetting about Yoda time. Never tried it, but there are so many deficiencies in the standard date and time API that we need something else.

Blame the Java 7 steering committee. Stephen Colebourne (one of the creators of Joda Time), presented JSR-310 for consideration and it was rejected. I haven't heard whether they're going to try again for v8 or not.

Winston
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
JSR-310 is still moving forward - see ThreeTen. Supposedly before Java 7 they only had a few small issues to work out (including leap seconds), but now it sounds like there's been substantial redesign. Still targeted for Java 8 though. We hope.

I didn't mention Joda time because (a) I really want to see a finished version of JSR-310 instead, and (b) for this particular problem, simple math with rounding is IMO easier than bringing a new jar file into a project and learning a new API. Which isn't that hard, of course - but simple math is, well, simpler.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mike Simmons wrote:JSR-310 is still moving forward - see ThreeTen.

Oh, good. Cheers for that.

Supposedly before Java 7 they only had a few small issues to work out (including leap seconds)...

I have to admit, I don't know what the issue is with them, because as far as you, me, the system clock, Date, and all Calendar classes are concerned, they simply don't exist. Seems to me it's one those things that people have heard about and assume its a "problem"; when in fact the actual need for them is quite specialized (eg, GPS).

Furthermore, if something like SLS is adopted, they may well simply disappear altogether.

for this particular problem, simple math with rounding is IMO easier...

Presuming it's documented. Personally, I like Jesper's suggestion the best because it follows the Ronseal philosophy ("it does exactly what it says on the tin").

Winston
 
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!