File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Date object or String?

 
Jay Brass
Ranch Hand
Posts: 76
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've been working in Java for awhile but never thought about this. I have a class that captures the current time. This has to be sent to a database. There seems to be a problem going from Java.util.Date to java.sql.Date. All of the hours, minutes and seconds get set to zero. The stored procedure doesn't return the right data since the data is time (and Date) sensitive. My question is, is there any taboo in creating a string from the Date object and passing it around? I will never change this since it represents a moment in time that I never have to add or delete from. It makes it a lot easier since SQLServer does the conversion from a string to DateTime for me. I also don't have to monkey around with Calendar or GregorianCalendar classes or deprecated date methods. I'm using Java 1.6
 
Alvin Watkins
Ranch Hand
Posts: 53
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I always do this by passing around Long's and using Timestamp(). Timestamp will take a java.util.Calendar or Date time-in-milliseconds and convert it to a Timestamp easily inserted into a DB or passed around and converted to whatever kind of "Date" you want (sql, Calendar or Date).
 
Jay Brass
Ranch Hand
Posts: 76
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yeah, I thought about TimeStamp, but the DBA warned me that he had a bad experience using TimeStamp in the past and got burned really bad. A Long would be OK but it doesn't make testing very easy. I can log or system.out Strings and they are readily readable. Just a little more to do if I put Longs out there. The other advantage to Strings is that SQLServer converted it for me.
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 64205
83
IntelliJ IDE Java jQuery Mac Mac OS X
  • 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
String conversion is strongly contra-indicated as it is interpreted in the local timezone. Keep is as a long and it represents the same point in time no matter where it is passed around.

Convert to a string only, and only ever, for display. Never for passing around.
 
Paul Clapham
Sheriff
Pie
Posts: 20208
26
MySQL Database
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jay Brass wrote:Yeah, I thought about TimeStamp, but the DBA warned me that he had a bad experience using TimeStamp in the past and got burned really bad.


This is called "Design by Rumour". Don't fall for it. When somebody tells you something vague like that, press them for details. I say this because the correct class to use is java.sql.Timestamp. It's certainly possible to get into trouble using it, but that's usually attributable to the person and not to the class.

So go back and ask for details. Or better still, just use the Timestamp class. If you're updating a database column which represents a date and time, that's what you should use. Actually... you should confirm that the database column is actually a date-time column and not something like a varchar column put there by a DBA who thought it was a good idea to do that.
 
Paul Clapham
Sheriff
Pie
Posts: 20208
26
MySQL Database
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just to clarify a bit: if you want to pass the date-with-time value around your Java code, then a long value is suitable. However when you want to update your database, a Timestamp object is the thing to use.
 
Alvin Watkins
Ranch Hand
Posts: 53
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm not sure what your DBA is talking about. I've used Timestamp for years and never had any problems. It just takes a long and converts it to a YYYY-MM-DD format that SQL will accept. Also, for testing, this seems pretty straightforward to me:

 
Jay Brass
Ranch Hand
Posts: 76
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


as opposed to
which would show 2013-02-07 15:30:25.123
I think I like using the string when I have formatted it with SimpleDateFormat. That being said, my question isn't how to get it to the database, it's about whether I should pass around a String or Date object. Passing a Long has some good points, but I think using the original object is the best idea. I don't know if I will need to use it in any other situation in the future and if I use a String or Long, I am limiting myself. I didn't realize this until I saw all of your postings. That got me thinking that a String puts me in a corner where I'm limited to what I can do with my Date time object.
This also sparked a new question, if I were to use a TimeStamp as has been suggested, and against the DBA's wishes, can SQLServer implicitly convert it to a DateTime type? There are hundreds of tables that have DateTime fields. I'd have to make someone go back and change them all to TimeStamps.
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 64205
83
IntelliJ IDE Java jQuery Mac Mac OS X
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jay Brass wrote:it's about whether I should pass around a String or Date object.


Which has been answered: no strings!

You can thank me in advance for warning you to avoid the timezone hell you will otherwise enter.
 
Paul Clapham
Sheriff
Pie
Posts: 20208
26
MySQL Database
  • 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jay Brass wrote:This also sparked a new question, if I were to use a TimeStamp as has been suggested, and against the DBA's wishes, can SQLServer implicitly convert it to a DateTime type? There are hundreds of tables that have DateTime fields. I'd have to make someone go back and change them all to TimeStamps.


That is exactly what the JDBC driver for the database does. Don't get confused between the type of the database column and the type of the Java object which represents it -- in the database the columns are DateTime fields, and in Java you use a Timestamp (not TimeStamp) object to represent it.

So if your DBA is competent to advise you on Java programming, and has power to veto what you do, then that advice should include sample code which uses something other than Timestamp to correspond to DateTime fields. I may be doing your DBA a disservice, but there are plenty of people who have had problems using Feature X in Java, and instead of fixing what they did wrong, they instead use horrible workarounds which avoid using Feature X. That may or may not be the case with your DBA.
 
Jay Brass
Ranch Hand
Posts: 76
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You guys are awesome. Thank you Bear Bibeault and Paul and everyone. Timestamp (not TimeStamp) is what I will use.
Thanks
 
Pat Farrell
Rancher
Posts: 4660
5
Linux Mac OS X VI Editor
  • 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just remember that in Java, a Date is a four letter word. The Date class was badly designed, most of its functionality has been deprecated, and even with that, its a terrible class. Sadly, the Calendar and GregorianCalendar classes are not much better. I found that to keep my head from exploding, remember:

1) a Date object is just the number of milliseconds from an arbitrary date and time.
2) a Date object does not have a timezone or locale
3) the assorted DateFormat classes have the timezone and locale.
4) keep your dates on the server and in the DBMS as UTC dates, and apply a local timezone and locale for the user.

The Java Timestamp is just a Date with a different name. Its more type safe.
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic