aspose file tools*
The moose likes Java in General and the fly likes 3 months Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "3 months " Watch "3 months " New topic
Author

3 months

Mary Cole
Ranch Hand

Joined: Dec 02, 2000
Posts: 362
Hi,
Is there a shorter way using JAVA API to get the date of 3 months bk date from current date(its not 90 days...but 3 months)

Its urgent pls help
Rovas Kram
Ranch Hand

Joined: Aug 08, 2003
Posts: 135
GregorianCalendar cal = new GregorianCalendar();
cal.setTime(new Date());// now
cal.add(cal.MONTH, 3);
Rovas Kram
Ranch Hand

Joined: Aug 08, 2003
Posts: 135
oops, you said back.

GregorianCalendar cal = new GregorianCalendar();
cal.setTime(new Date());// now
cal.roll(cal.MONTH, -3);
Julian Kennedy
Ranch Hand

Joined: Aug 02, 2004
Posts: 823
It always makes me uncomfortable when I see GregorianCalendar being instantiated explicitly. Although there's currently no alternative concrete implementation of Calendar in the Platform the forward-compatible usage would be:

Call me anal, but you shouldn't need to change it that way.

Jules
[ August 13, 2004: Message edited by: Julian Kennedy ]
Rovas Kram
Ranch Hand

Joined: Aug 08, 2003
Posts: 135
Julian,

I chose to use GregorianCalendar because Calendar.add is abtract. Are you saying never to use GregorianCalendar? What are you saying?
Julian Kennedy
Ranch Hand

Joined: Aug 02, 2004
Posts: 823
Hi Rovas,

I suppose I am saying never use GregorianCalendar explicitly, yes. Unless it's for a really noddy example that you're not going to use in a real application, but even then there's no good reason as there's no advantage in typing new GregorianCalendar() over Calendar.getInstance(). Now I come to count the letters (sad, I know:rolleyes it's actually shorter!

GregorianCalendar is a concrete instance of the abstract Calendar class, i.e. it provides an implementation of the add() method and other abstract methods. When you call Calendar.getInstance() you get an implementation of Calendar appropriate to the locale. You're very likely to get a GregorianCalendar anyway, but you shouldn't assume that. Certain countries, like many in the Arab world don't use the Gregorian calendar as standard. So, if you were creating software that you planned to make available to all and sundry over the Internet, for example, it may prove to be unusable (or at least unhelpful) to some of your potential users.

So, there you go. Hope that clears it up.

Jules
Rovas Kram
Ranch Hand

Joined: Aug 08, 2003
Posts: 135
Thanks for clearing the up Julian - I didn't know I would get a GregorianCalendar object if I called Calendar.getInstance(). Would you please tell me what your source is for your conviction that one should only call Calendar.getInstance()? It certainly is not in the Java API. In fact, there a public constructors for GregorianCalendar that provide initialization options beyond that of the getInstance method.
[ August 16, 2004: Message edited by: Rovas Kram ]
Mary Cole
Ranch Hand

Joined: Dec 02, 2000
Posts: 362
Thx for the reply Guys,
But how do i get that date in MM/dd/YYYY format
Stefan Krompass
Ranch Hand

Joined: Apr 29, 2004
Posts: 75
Hi,

you get a Date-object when you call Calendar#getTime(). Using DateFormat might lead to what you want.

Stefan
Julian Kennedy
Ranch Hand

Joined: Aug 02, 2004
Posts: 823
OK, the GregorianCalendar Javadoc says:
GregorianCalendar is a concrete subclass of Calendar and provides the standard calendar used by most of the world.

The Calendar Javadoc says:
Subclasses of Calendar interpret a Date according to the rules of a specific calendar system. The platform provides one concrete subclass of Calendar: GregorianCalendar. Future subclasses could represent the various types of lunar calendars in use in many parts of the world.

Like other locale-sensitive classes, Calendar provides a class method, getInstance, for getting a generally useful object of this type. Calendar's getInstance method returns a Calendar object whose time fields have been initialized with the current date and time:

Calendar rightNow = Calendar.getInstance();

A Calendar object can produce all the time field values needed to implement the date-time formatting for a particular language and calendar style (for example, Japanese-Gregorian, Japanese-Traditional).

Now, if you directly instantiate a GregorianCalendar instead of using Calendar.getInstance() you're enforcing your choice on your Japanese-Traditional users. This would (probably unnecessarily) require you to modify your application later should you need to support internationalization (i18n). There are few good reasons for doing this.

If you feel you need to use the convenience constructors on GregorianCalendar to create a Calendar object for a specific date/time you can achieve the same thing, supporting i18n, using:

Looking up GregorianCalendar in O'Reilly's Java in a Nutshell it says:
You do not typically use this class directly, but instead obtain a Calendar object suitable for the default locale...


When you encounter an instance of the factory pattern, like Calendar, it rarely makes good sense to go and create your own object rather than getting it from the factory.

I'd be interested to hear of a valid, uncontrived, use for GregorianCalendar without Calendar.getInstance() (following best practice).

Any better?

Jules
Julian Kennedy
Ranch Hand

Joined: Aug 02, 2004
Posts: 823
Hi Mary,

Further to previous responses, please be aware that you should be using something like the following:

If you use cal.roll() then rolling -3 months from, say, 31-Mar-2004 will give you 31-Dec-2004, not 2003 like you might be expecting.

Since I've been banging on about i18n and factory classes I should probably mention the other way of doing date formatting:


Apparently this factory typically returns a SimpleDateFormat object but, as SimpleDateFormat provides functionality for custom date formatting (as you require), which requires various methods not supported by the abstract DateFormat class, you can't access that functionality without first checking the type of the returned object, which defeats the object of using a factory. So, you're better off just instantiating a new SimpleDateFormat in this case.

Jules
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Month math always worries me. Make sure all your users and testers and so on agree on what 3/31 - 1 month is. Like, do they care whether (3/31 - 3 months) != (3/31 - 1 month - 1 month - 1 month)?


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
It always makes me uncomfortable when I see GregorianCalendar being instantiated explicitly.

I dunno. I agree with the general idea here: try to refer to objects by the most general type that meets your needs, to make it easier to use a different subtype later, if necessary. However I'm inclined to think that Calendar and GregorianCalendar are poor examples of this. The fact that there are no Calendar subclasses besides GregorianCalender even after more than seven years since JDK 1.1 came out is a clue, I think. Calendar just isn't very useful for anything other than a GregorianCalendar - or something very closely related, such as a Julian calendar (and how often does that come up anyway? Plus it's already implicitly included in a GregorianCalendar). Note how many of the constants associated with Calendar are specific to a Western (Gregorian) calendar - MONDAY, JANUARY, etc. What would these mean on a Muslim, Jewish, or Hindu calendar? And what's a month, anyway? I strongly agree with Stan's post - calculations involving adding or subtracting months are extremely suspicious already using Gregorian calendars. This just gets worse if you allow the possibility that the user is actually using some other calendar. How many days are in a month? 30? 31? 28? 29? 19?

Basically, I think any attempt to allow user preferences to define a calendar will be extremely bug-prone, and basically a bad idea. Better IMO to just use a GregorianCalendar and at least ensure that all your users are getting consistent results. Better still - don't add or subtract months, ever. The results probably don't mean the same thing to different people.

Now you can still provide a fair amount of user-specific internationalization when it comes to formatting. That is, if you use DateFormat.getDateTimeInstance() rather than new SimpleDateFormat(whatever), you will probably get a format which is appropriate for the user in question. However, this only works if the data you're providing is just going to be used on the user's own machine. If you're writing a file that will be e-mailed to someone else, or sending data across a network connection, you have to ask yourself whether the defaults on the other side of the connection are the same as the ones on your side. Often, they're not (or not necessarily). In such situations it may be better to adopt a common standard for everyone to use. This is a common problem that also shows up for things like file encodings. If a file is only used on one machine, use default encoding - if it is passed to other machines which may have different defaults, don't use default encoding.
[ August 16, 2004: Message edited by: Jim Yingst ]

"I'm not back." - Bill Harding, Twister
Sonny Gill
Ranch Hand

Joined: Feb 02, 2002
Posts: 1211

Hmm..very helpful posts Julian, Stan and Jim. This is something I have tried to avoid thinking too hard about as that gives me a headache, but you guys make it hard for me to keep doing that


The future is here. It's just not evenly distributed yet. - William Gibson
Consultant @ Xebia. Sonny Gill Tweets
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608

It always makes me uncomfortable when I see GregorianCalendar being instantiated explicitly.


I agree.
I get the same feeling every time I see code that has been unnecessarily implemented in a platform dependant manner.
That is, favouring platform dependency with ackowledgement and justification I'm fine with - but doing it unknowingly or unnecessarily is just ick.


Tony Morris
Java Q&A (FAQ, Trivia)
 
jQuery in Action, 2nd edition
 
subject: 3 months