1

I have a simple java object with several date properties and I always seem to change my mind on how to define them. Should the properties be defined as date objects or strings? The object is going to be used in struts 1.3 application with iBatis as the persistence layer and mysql as the database. The database columns are defined as datetime and they can possibly be null and I usually don’t care about the time portion.

public Date getForcastDate();

or 

public String getForcastDate();

Most of the existing code base uses strings, but that just doesn’t seem quite right to me.

jzd
  • 23,473
  • 9
  • 54
  • 76
xecaps12
  • 5,316
  • 3
  • 27
  • 42

5 Answers5

6

Keep your dates as Dates. That way you can change formatting depending on locales, check for invalid dates, sort by them etc.

By keeping them as strings you're potentially throwing away data (e.g. milliseconds if your formatter doesn't use them) and definitely behaviour.

Using strong-typing (e.g. keeping them as Dates) will aid in terms of development. Your method signatures become clearer, refactoring using IDE tooling becomes easier etc. Otherwise you end up with APIs that talk in nothing but strings, it's trivial to mix up parameters, and it becomes impossible to work out what's going on.

Tip: Check out Joda-Time as a better alternative to the standard java.util.Date.

Brian Agnew
  • 268,207
  • 37
  • 334
  • 440
  • This is the route I was thinking of going. Seems to make the most sense. I think we've got Joda in some of our code, I'll probably try that. Thanks. – xecaps12 Mar 09 '11 at 14:41
  • FYI, the [*Joda-Time*](http://www.joda.org/joda-time/) project is now in [maintenance mode](https://en.wikipedia.org/wiki/Maintenance_mode), advising migration to the [*java.time*](http://docs.oracle.com/javase/10/docs/api/java/time/package-summary.html) classes. See [Tutorial by Oracle](https://docs.oracle.com/javase/tutorial/datetime/TOC.html). – Basil Bourque Oct 20 '18 at 21:22
1

I would use Date object because it cleaner to store a Date and convert it to a String when needed. Otherwise you have to hard code a formatted date into a String field.

jzd
  • 23,473
  • 9
  • 54
  • 76
1

I would never use Strings in this cas as what would today be 8/3/11 or 3/8/11 or 2011-03-08. This is really a specific case of trying to use the most restrictive type/class possible for a variable. This is so that you can understand its behaviour more fully, both by having a restricted or specialised set of methods and by helping documentation of other classes using it. Using a Date here would allow you to use a Calendar object to add days or months. Conversion to or from a string only needs to be done for input and output.

In practice if they were only dates I would crete my own Date class so could ignore times or use JodaTime which provides easier manipulation than the java Date

mmmmmm
  • 32,227
  • 27
  • 88
  • 117
1

In my code I always use the most high level object. In this case I would suggest - Calendar. Here is separate discussion about Date and Calendar. I always think this way - converting Calendar/Date to String is simple - use SimpleDateFormatter. But very often you will need to do something with the date (add several days or hours, subtract a year, handle timezones etc) and then each time you would have to convert it from String to Calendar/Date.

Community
  • 1
  • 1
Sebastian Łaskawiec
  • 2,667
  • 15
  • 33
0

Date if you had to, but java.util.Calendar would probably be more appropriate nowadays. With a String you'd have to worry about format like @jzd mentioned. With Calendar, you can easily switch between formats. Also Calendar lets you get at the date with Calendar.getTime()

Simeon G
  • 1,188
  • 8
  • 20