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
cal.setTime(new Date());// now
GregorianCalendar cal = new GregorianCalendar();
cal.setTime(new Date());// now
Call me anal, but you shouldn't need to change it that way.
[ August 13, 2004: Message edited by: Julian Kennedy ]
I chose to use GregorianCalendar because Calendar.add is abtract. Are you saying never to use GregorianCalendar? What are you saying?
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.
[ August 16, 2004: Message edited by: Rovas Kram ]
But how do i get that date in MM/dd/YYYY format
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).
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.
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 ]
It always makes me uncomfortable when I see GregorianCalendar being instantiated explicitly.
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.