File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Java in General and the fly likes Date object or String? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Date object or String?" Watch "Date object or String?" New topic
Author

Date object or String?

Jay Brass
Ranch Hand

Joined: Oct 24, 2000
Posts: 76
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

Joined: May 25, 2011
Posts: 53
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

Joined: Oct 24, 2000
Posts: 76
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

Joined: Jan 10, 2002
Posts: 61106
    
  66

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.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

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
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

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

Joined: May 25, 2011
Posts: 53
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

Joined: Oct 24, 2000
Posts: 76


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

Joined: Jan 10, 2002
Posts: 61106
    
  66

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
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

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

Joined: Oct 24, 2000
Posts: 76
You guys are awesome. Thank you Bear Bibeault and Paul and everyone. Timestamp (not TimeStamp) is what I will use.
Thanks
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4650
    
    5

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.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Date object or String?