tl;dr
LocalDateTime.parse(
"2012-07-10 14:58:00.000000".replace( " " , "T" )
)
Microseconds do not fit
You are attempting to squeeze a value with microseconds (six decimal digits) into a data type capable only of milliseconds resolution (three decimal digits). That is impossible.
Instead, use a data type with fine enough resolution. The java.time classes use nanosecond resolution (nine decimal digits).
Unzoned input does not fit a zoned type
You are attempting to put a value lacking any offset-from-UTC or time zone into a data type (Date
) that only represents values in UTC. So you are adding information (UTC offset) not intended by the input.
Use an appropriate data type instead. Specifically, java.time.LocalDateTime
.
Case-sensitive
Other Answers and Comments correctly explain that the formatting pattern codes are case-sensitive. So MM
and mm
have different effects.
Avoid legacy classes
The troublesome old date-time classes bundled with the earliest versions of Java are now legacy, supplanted by the java.time classes built into Java 8 and later.
ISO 8601
Your input strings nearly comply with the ISO 8601 standard formats. Replace the SPACE in the middle with a T
to comply fully.
The java.time classes use the standard formats by default when parsing/generating strings. So no need to specify a formatting pattern.
Date-time objects have no "format"
and I need the resultant date object to be of the same format.
No, date-time objects do not have a "format". Do not conflate date-time objects with mere strings. Strings are inputs and outputs of the objects. The objects maintain their own internal representions of the date-time info, the details of which are irrelevant to us as calling programmers.
java.time
Your input lacks any indicator of offset-from-UTC or troublesome me zone. So we parse as a LocalDateTime
objects which lacks those concepts.
String input = "2012-07-10 14:58:00.000000".replace( " " , "T" ) ;
LocalDateTime ldt = LocalDateTime.parse( input ) ;
Generating strings
To generate a String representing the value of your LocalDateTime
:
- Call
toString
to get a String in standard ISO 8601 format.
- Use
DateTimeFormatter
for producing strings in either custom formats or automatically-localized formats.
Search Stack Overflow for more info as these topics have been covered many many times already.
ZonedDateTime
A LocalDateTime
does not represent an exact point on the timeline.
To determine an actual moment, assign a time zone. For example noon in Kolkata India comes much earlier than noon in Paris France. Noon without a time zone could be happening at any point over a range of about 26-27 hours.
ZoneId z = ZoneId.of( "Asia/Kolkata" ) ;
ZonedDateTime zdt = ldt.atZone( z ) ;
About java.time
The java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date
, Calendar
, & SimpleDateFormat
.
To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.
The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.
You may exchange java.time objects directly with your database. Use a JDBC driver compliant with JDBC 4.2 or later. No need for strings, no need for java.sql.*
classes. Hibernate 5 & JPA 2.2 support java.time.
Where to obtain the java.time classes?