The other Answers are correct but now outdated. They use troublesome old classes now supplanted by the java.time framework.
Using java.time
The input string happens to comply with ISO 8601 standard formatting. So no need to specify a formatting pattern as the java.time classes use ISO 8601 by default when parsing/generating strings.
The input string includes an offset-from-UTC, so we parse as an OffsetDateTime
.
String input = "2010-12-15T16:26:49.841-08:00" ;
OffsetDateTime odt = OffsetDateTime.parse( input );
If you have a specific time zone in mind, rather than a mere offset-from-UTC, apply that.
ZoneId zoneId = ZoneId.of( "America/Los_Angele" );
ZonedDateTime zdt = odt.atZone( zoneId );
GregorianCalendar
You should avoid the old date-time classes such as GregorianCalendar
. But if you must to interoperate with old code not yet updated for java.time, you can convert. Use new methods added to the old classes for conversion. For more info and a nifty diagram, see my Question and Answer.
Calendar cal = java.util.GregorianCalendar.from( zdt ); // Do such conversions out of java.time only if absolutely necessary.
About java.time
The java.time framework is built into Java 8 and later. These classes supplant the old troublesome date-time classes such as java.util.Date
, .Calendar
, & java.text.SimpleDateFormat
.
The Joda-Time project, now in maintenance mode, advises migration to java.time.
To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations.
Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport and further adapted to Android in ThreeTenABP.
The ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time. You may find some useful classes here such as Interval
, YearWeek
, YearQuarter
, and more.