Convert a String to a Date

problem may be in how you insert it, check that code

Think this will work:

private static Date getDate(String dateString){
            Date date = null;
            try{
                  SimpleDateFormat df = new SimpleDateFormat("MM/dd/yyyy");
                  date =  df.parse(dateString);
            }catch(Exception e){
                  e.printStackTrace();
            }
            return date;
            
      }
SimpleDateFormat sdf = new SimpleDateFormat("dd-MMM-yyyy HH:mm")
but, the value in the example above always winds up being something like this:
03-SEP-1016 14:0
This is because you have formatted it in that way!
Give the code a try!
Regards

>>This is because you have formatted it in that way!

S/he hasn't actually ;-)

:))
Got you!
But wont my code work if all I want is 04/04/2006?

It will. But that format doesn't seem to be what s/he wants

Which database are you using? (SQL Server/Oracle etc)

A) Java date sucks, use Joda Time
http://joda-time.sourceforge.net/


B)This seems to work, but, the value in the example above always winds up being something like this:
After this:
       date =  df.parse(dateString);
date = 03-SEP-1016 14:0 ???
Or does your new DATABASE value = 03-SEP-1016 14:0 ???

dd-MMM-yyyy HH:mm Your database may not be recognizing this format
If it is database value, how do you put Date value into your database.

It may be a view issue. Could be that whatever you're viewing the date through does not use the same format (00==0)

CEHJ,

As you requested:

Source_Field contains the following text value:  "03-SEP-2006 14:00"

Code to convert from String to Date looks like this:

Public static Date convertStringToDate(String inputStrDate) {
     Date newDate = null;
     SimpleDateFormat dFormat = new SimpleDateFormat("dd-MMM-yyyy HH:mm")
     newDate = dFormat.parse(inputStrDate)

    return newDate;
}

*****

As all can see, the above code is rather simple, and I would have expected it to work. What complicates matters is that I am testing to see if the date looks OK using a Web-based app, and the date does not look right there. The app is a fairly hefty J2EE Java-based website that serves up customer data to internal CS personnel. I did not code the app, and there is a certain level of disconnection between me and the developers. Further complicating matters is the fact that Toplink generated the Oracle schema, so it is difficult to discern where exactly all of the migrated data is being placed (I engage the DB at the Toplink object model level, which bears little resemblance to the actual db schema).

>It may be a view issue. Could be that whatever you're viewing the date through does not use the same format (00==0)

Well, that might indeed be true. I should ammend my original post and say that the date, aftering being migrated, looks like this:

03-AUG-1016 14:0

Now, your comment would address why the time looks funky, but not why the month and year appear to be off by:

Month: 1
Year: 1900

This happens consistently, no matter what date value I attempt to convert. The month is always less by 1 (OCT becomes SEP, etc.) and the year is always less by 1900 years.

Perhaps I will not find the answer directly, but your comments may at least point me in the right direction. I, being a novice, find myself drowning in a sea of Java.

>>03-AUG-1016 14:0

Is looking more alarming. Try to print it out as a long type to ensure that the model has not changed

CEHJ,

I have come to the same conclusion. I think it has something to do with how the app's date formatter is parsing out date values for the view. Thanks for the insight.

PF888

:-)

You can establish the truth of that by printing the long value and comparing it with the original. Beware of numerical signing issues

Well, this I did compare the converted value to the original value (a comparison of long value to long value) and it looked right. So, the problem would either have to be at the DB or presentation layer. I believe it is at the pres layer - the underlying db field is a Date datatype, so do not think I would have an issue there.