0

I have a date string in this format:

String fieldAsString = "11/26/2011 14:47:31";

I am trying to convert it to a Date type object in this format: "yyyy.MM.dd HH:mm:ss"

I tried using the following code:

SimpleDateFormat sdf = new SimpleDateFormat("yyyy.MM.dd HH:mm:ss");
Date newFormat = sdf.parse(fieldAsString);

However, this throws an exception that it is an Unparsable date.

So I tried something like this:

Date date = new SimpleDateFormat("MM/dd/yyyy HH:mm:ss").parse(fieldAsString);
String newFormat = new SimpleDateFormat("yyyy.MM.dd HH:mm:ss").format(date)

However, this new format is now in the 'String' format but I want my function to return the new formatted date as a 'Date' object type. How would I do this?

Thanks!

A Y
  • 177
  • 2
  • 3
  • 13

2 Answers2

6

You seem to be under the impression that a Date object has a format. It doesn't. It sounds like you just need this:

Date date = new SimpleDateFormat("MM/dd/yyyy HH:mm:ss").parse(fieldAsString);

(You should consider specifying a locale and possibly a time zone, mind you.)

Then you've got your Date value. A format is only relevant when you later want to convert it to text... that's when you should specify the format. It's important to separate the value being represent (an instant in time, in this case) from a potential textual representation. It's like integers - there's no difference between these two values:

int x = 0x10;
int y = 16;

They're the same value, just represented differently in source code.

Additionally consider using Joda Time for all your date/time work - it's a much cleaner API than java.util.*.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • Re the sentence in parentheses - I agree about specifying a time zone, definitely. But specifying a locale - why would you do this? If the format is `"MM/dd/yyyy HH:mm:ss"` then there's nothing in there that's locale dependent. – Dawood ibn Kareem Feb 11 '14 at 19:28
  • @DavidWallace: The calendar system depends on the locale. I suspect the OP always wants to use the Gregorian calendar. (I'd *expected* the date and time separators to depend on the locale too, but apparently they don't in SimpleDateFormat.) – Jon Skeet Feb 11 '14 at 19:31
  • Wow, really? So if I set the locale of a `SimpleDateFormat` to Iran, it will work with the Persian calendar? That's kind of cool. I see I have some experimenting to do. :-) – Dawood ibn Kareem Feb 11 '14 at 19:44
  • @DavidWallace: Not sure about the Persian calendar, but I believe you can get a Buddhist calendar for Thailand, for example...# – Jon Skeet Feb 11 '14 at 19:45
  • Thank you, Jon; I have a feeling I'm going to have some fun today. Have an upvote! – Dawood ibn Kareem Feb 11 '14 at 19:47
  • Right you are. It seems that the JDK will let me have a Gregorian calendar, a Buddhist calendar, or a Japanese Imperial calendar, depending on my locale. I would feel really cheated if I lived in Saudi Arabia, Afghanistan or Iran. I wonder who makes the decisions about what things to include in cases like this! – Dawood ibn Kareem Feb 12 '14 at 03:04
0

The answer by Jon Skeet is correct and complete.

Internal to java.util.Date (and Date-Time seen below), the date-time value is stored as milliseconds since the Unix epoch. There is no String inside! When you need a textual representation of the date-time in a format readable by a human, either call toString or use a formatter object to create a String object. Likewise when parsing, the input string is thrown away, not stored inside the Date object (or DateTime object in Joda-Time).

Joda-Time

For fun, here is the (better) way to do this work with Joda-Time, as mentioned by Mr. Skeet.

One major difference is that while a java.util.Date class seems to have a time zone, it does not. A Joda-Time DateTime in contrast does truly know its own time zone.

String input = "11/26/2011 14:47:31";

// From text to date-time.
DateTimeZone timeZone = DateTimeZone.forID( "Pacific/Honolulu" ); // Time zone intended but unrecorded by the input string.
DateTimeFormatter formatterInput = DateTimeFormat.forPattern( "MM/dd/yyyy HH:mm:ss" ).withZone( timeZone );
// No words in the input, so no need for a specific Locale.
DateTime dateTime = formatterInput.parseDateTime( input );

// From date-time to text.
DateTimeFormatter formatterOutput_MontréalEnFrançais = DateTimeFormat.forStyle( "FS" ).withLocale( java.util.Locale.CANADA_FRENCH ).withZone( DateTimeZone.forID( "America/Montreal" ) );
String output = formatterOutput_MontréalEnFrançais.print( dateTime );

Dump to console…

System.out.println( "input: " + input );
System.out.println( "dateTime: " + dateTime );
System.out.println( "dateTime as milliseconds since Unix epoch: " + dateTime.getMillis() );
System.out.println( "dateTime in UTC: " + dateTime.withZone( DateTimeZone.UTC ) );
System.out.println( "output: " + output );

When run…

input: 11/26/2011 14:47:31
dateTime: 2011-11-26T14:47:31.000-10:00
dateTime as milliseconds since Unix epoch: 1322354851000
dateTime in UTC: 2011-11-27T00:47:31.000Z
output: samedi 26 novembre 2011 19:47

Search StackOverflow for "joda" to find many more examples.

Community
  • 1
  • 1
Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154