Win a copy of Learn Spring Security (video course) this week in the Spring forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

3 months

 
Mary Cole
Ranch Hand
Posts: 362
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 135
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
GregorianCalendar cal = new GregorianCalendar();
cal.setTime(new Date());// now
cal.add(cal.MONTH, 3);
 
Rovas Kram
Ranch Hand
Posts: 135
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
oops, you said back.

GregorianCalendar cal = new GregorianCalendar();
cal.setTime(new Date());// now
cal.roll(cal.MONTH, -3);
 
Julian Kennedy
Ranch Hand
Posts: 823
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 135
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 823
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 135
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 362
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thx for the reply Guys,
But how do i get that date in MM/dd/YYYY format
 
Stefan Krompass
Ranch Hand
Posts: 75
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

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

Stefan
 
Julian Kennedy
Ranch Hand
Posts: 823
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 823
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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)?
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Sonny Gill
Ranch Hand
Posts: 1211
IntelliJ IDE Mac
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic