tl;dr
Always use java.time classes, never the terrible legacy classes such as java.util.Date. To interoperate, convert.
I suspect you actually intended standard ISO 8601 format such as 2009-12-31T23:59:59.999Z.
Do not be tripped-up by the anti-feature in Date::toString that dynamically applies a time zone to a value that is actually in UTC.
The java.time classes are thread-safe by design, using immutable objects. So no need for the synchronized calls.
public class DateAdapter extends XmlAdapter< String, Date > {
@Override
public String marshal( Date v ) throws Exception { // `Instant` generates standard ISO 8601 strings by default. No need to specify a formatting pattern.
return v.toInstant().toString() ; // Convert from legacy `Date` to modern `Instant`.
}
@Override
public Date unmarshal( String v ) throws Exception { // `Instant` parses standard ISO 8601 strings by default. No need to specify a formatting pattern.
return java.util.Date.from( Instant.parse( v ) ) ; // Convert from modern `Instant` to legacy `Date`.
}
}
ISO 8601
Your input string is close to standard ISO 8601 format. I strongly recommend sticking with the standard wherever possible. Omit the SPACE before the offset-from-UTC.
And, best to include the COLON in the offset between the hours and minutes — while optional in the standard, some libraries expect the character.
String input = "2009-12-31T23:59:59.999+00:00" ;
By the way, a common abbreviation of an offset-from-UTC of zero is the letter Z, pronounced “Zulu”.
String input = "2009-12-31T23:59:59.999Z" ;
java.time
You are using terrible date-time classes bundled with the earliest versions of Java. Those legacy classes were supplanted entirely years ago by the java.time classes.
Check to see if your libraries have been updated to work with java.time. If not, you can convert back-and-forth by calling new methods added to the old classes.
A java.util.Date object is a moment, a point on the timeline in UTC. Now replaced by the java.time.Instant class.
Instant instant = myJavaUtilDate.toInstant() ; // Convert by calling new method added to the old class.
To generate a string in the standard format with a Z, just call toString.
String output = instant.toString() ;
Parsing a string in standard format is simple with Instant.parse. No need to specify a formatting pattern.
Instant instant = Instant.parse( "2009-12-31T23:59:59.999Z" ) ;
Convert using another new method added to the old class.
java.util.Date d = java.util.Date.from( instant ) ;
If you cannot change to using standard ISO 8601 text formats, use a DateTimeFormatter object to parse and generate strings in alternate formats. Search Stack Overflow as this has been covered many many times already.
Date::toString lies
Be aware that java.util.Date::toString lies to you. That method dynamically applies the JVM’s current default time zone. The internal value is in UTC, but this method reports otherwise. While well-intentioned, this anti-feature has caused no end of confusion and misery among Java programmers. In contrast, the java.time classes report their values directly without such opinionated injections.
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.
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.
