• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Devaka Cooray
  • Knute Snortum
  • Paul Clapham
  • Tim Cooke
Sheriffs:
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Frits Walraven
Bartenders:
  • Ganesh Patekar
  • Tim Holloway
  • salvin francis

Date vs GregorianCalender  RSS feed

 
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When should i use Date and when should go for GregorianCalender?
 
Ranch Hand
Posts: 129
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Methods in Date been mostly deprecated. There is very little you are encouraged to do with it other than compare two Dates or display the Date in the default format. GregorianCalendar is useful if you are using it across the BC/AD transition.

If you are using it for custom displays in contemporary times, use Calendar and SimpleDateFormat.
 
Bartender
Posts: 1840
Eclipse IDE Java Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You should rarely use GregorianCalendar explicitly; if you need to use a Calendar, call Calendar.getInstance() and use whatever subclass of Calendar is returned.

That said, you really only need to use Calendars when doing date manipulation (adding days, etc.). Most of the time, I find that I am simply storing and displaying dates, and java.util.Date and java.text.DateFormat are sufficient for that task. I rarely use Calendar, except in utility methods.
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[Darryl]: Methods in Date been mostly deprecated. There is very little you are encouraged to do with it other than compare two Dates or display the Date in the default format.

I disagree. Just because many of the original methods and constructors were ill-conceived does not mean that the remaining constructors and methods should not be used. For example the DateFormat class (and SimpleDateFormat) certainly use Dates when parsing and formatting. A Date is a simple, small object, very convenient for simply representing a date/time. The only thing smaller and simpler is a long (the one you'd get from Date.getTime()).

But using Date instead has a very important benefit - it automatically documents that the data here represents a date/time. If you pass a long around, there's more chance that another programmer will see the data without understanding its significance (the fact that it represents milliseconds since 000 GMT, Jan 1, 1970) unless you spend extra effort documenting this. By using Date, that becomes obvious. All the documentation you need is already present in the class.

I agree with Joel's statements about Calendars. For many applications they're needlessly complex, and contain many possible sources of error for programmers. (E.g. day of month starts with 1, but month starts with 0.) I avoid using Calendar except when the nature of the problem requires it. I find at least 3/4 of the time, Date and DateFormat (or SimpleDateFormat) are all I need.

If you find you need to do a lot of date/time calculations, I recommend the Joda Time library. It's much less painful to use than Calendar.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The TimeAndMoney package has some things that work and are good for your brain, too. Read their pitch; I can't say any more than that.
[ September 23, 2006: Message edited by: Stan James ]
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!