I had code that parses date as follows:
String ALT_DATE_TIME_FORMAT = \"yyyy-MM-dd\'T\'HH:mm:ss.SSSZ\";
SimpleDateFormat sdf = new SimpleDateFormat(
As a more concrete example to @Pangea's suggestion to use JodaTime, this is what you could use:
String timestamp = "2012-09-17T04:11:46Z";
DateTime date = ISODateTimeFormat.dateTimeParser().parseDateTime(timestamp);
This correctly recognizes the UTC timezone. I haven't tried it with milliseconds in the string timestamp, but I'm confident it'll work just as well.
Hope that helps others.
JP
SimpleDateFormat only accepts -0800
or GMT-08:00
as the timezone.
It seems the ISO 8601 format can not be parsed with SimpleDateFormat
. Maybe you should have a look at Apache Commons Lang's FastDateFormat. It is compatible with SimpleDateFormat
but accepts the ZZ
pattern for the timezone that should parse the timezone format you need. DateFormatUtils contains some example constants that look like the pattern you need, just without the milliseconds (for example ISO_DATETIME_TIME_ZONE_FORMAT).
Try to change it to lower case z.
z processes most of the common general timezone syntax, while Z uses stricter RFC 822 time zone with 4 digits.
Although its documented that both should parse 'General timezone settings', it might make the difference in your case.
OffsetDateTime.parse( "2010-12-27T10:50:44.000-08:00" )
The input string format is defined in the ISO 8601 standard, a family of date-time formats.
The Question and other Answers use old outmoded date-time classes bundled with the earliest versions of Java. Avoid them. Now supplanted by the java.time classes.
Your input string ends with an offset-from-UTC. So we parse as a OffsetDateTime object.
The java.time classes use ISO 8601 formats by default when parsing/generating strings. So no need to specify a formatting pattern.
OffsetDateTime odt = OffsetDateTime.parse( "2010-12-27T10:50:44.000-08:00" );
If you want to view this date-time value as a moment on the timeline in UTC, extract an Instant
.
Instant instant = odt.toInstant();
A time zone is an offset plus a set of rules for handling anomalies such as Daylight Saving Time (DST). If you have a time zone in mind, apply a ZoneId
to get a ZonedDateTime
object. Same moment on the timeline, but viewed through a different wall-clock time.
ZoneId z = ZoneId.of( "America/Montreal" );
ZonedDateTime zdt = odt.atZoneSameInstant( z ); // Same moment on the timeline, but viewed through a different wall-clock 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.
The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.
To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.
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.
Where to obtain the java.time classes?
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.
The question should be where requiredTimeStamp
is coming from and in which format. Is it entered by a user, or read from another program? Which component creates the date in the String representation?
The format "2010-12-27T10:50:44.000-08:00" looks like standardized format ISO-8601
It should be parseable with the pattern yyyy-MM-dd'T'HH:mm:ss.SSSZ
Not sure which settings affect this, but there is an Oracle FAQ about Java TimeZones.
It may be user.timezone
system property or the /etc/localtime
symlink in RHEL.
If you want to parse it using straight JDK, i believe it should be parseable using the JAXB utils, see DatatypeFactory.newXMLGregorianCalendar or DatatypeConverter.parseDateTime.