tl;dr
Use the modern java.time classes that supplanted Joda-Time.
LocalDateTime // Represent a date and time-of-day without the context of a time zone or offset-from-UTC. *Not* a moment, *not* a point on the timeline.
.parse( // Parse text into a date-time value.
"2010-10-03 18:58:07".replace( " " , "T" ) // Replace SPACE in middle with a `T` to comply with ISO 8601 standard used by default in *java.time* when parsing/generating strings.
) // Returns a `LocalDateTime` object.
.atZone( // Assign the time zone we know for certain was intended for this input.
ZoneId.of( "Europe/Moscow" ) // Real time zones are named in `Continent/Region` format, never 2-4 letter codes such as CST, PST, IST, CEST, etc.
) // Returns a `ZonedDateTime` object, a date with time-of-day and with a time zone assigned to determine a moment.
.toInstant() // Adjust from time zone to UTC.
.equals(
OffsetDateTime // Represent a date and time-of-day with an offset-from-UTC but not a full time zone.
.parse( "2010-10-03T16:58:07.000+02:00" ) // Parse a standard ISO 8601 string.
.toInstant() // Adjust from offset to UTC (in other words, an offset of zero hours-minutes-seconds).
) // Returns `boolean`.
true
Details
The Answer by jarnbjo is correct in that you misunderstood the meanings of the offset-from-UTC and time zone values.
Now in 2018, the Joda-Time project is in maintenance-mode. That project’s principal author, Stephen Colebourne, went on to found JSR 310 and author its implementation, the java.time classes found in OpenJDK.
First input
Your input string 2010-10-03 18:58:07 is nearly in standard ISO 8601 format. To comply, replace the SPACE in the middle with a T.
String input1 = "2010-10-03 18:58:07".replace( " " , "T" ) ;
That string lacks any indicator of time zone or offset-from-UTC. So parse as a LocalDateTime.
LocalDateTime ldt = LocalDateTime.parse( input1 ) ;
This value does not represent a moment, is not a point on the timeline. Without the context of a zone or offset, it could be any of many moments within a range of about 26-27 hours, the range of time zones around the globe.
In your comments you revealed that apparently that input string was meant to represent a date and time-of-day in the Europe/Moscow time zone. So we can assign that zone to determine a moment, a point on the timeline.
ZoneId zMoscow = ZoneId.of( "Europe/Moscow" ) ;
ZonedDateTime zdtMoscow = ldt.atZone( zMoscow ) ; // Determine a moment by assigning a time zone.
zdtMoscow.toString(): 2010-10-03T18:58:07+04:00[Europe/Moscow]
Second input
Your second input 2010-10-03T16:58:07.000+02:00complies with standard ISO 8601 format.
This input carries an offset-from-UTC of two hours ahead of UTC. So this string represents the time-of-day of 14:58:07 in UTC.
We can parse as a OffsetDateTime to respect the given offset.
OffsetDateTime odt2 = OffsetDateTime.parse( "2010-10-03T16:58:07.000+02:00" ) ;
odt2.toString(): 2010-10-03T16:58:07+02:00
Compare
Do these two inputs represent the same moment, the same point on the timeline?
One way to compare is by adjusting both to UTC. An Instant is always in UTC, by definition.
Tip: Get in the habit of thinking, working, storing, exchanging, and logging in UTC. Think of UTC as The One True Time.
Instant instant1 = zdtMoscow.toInstant() ; // Adjust from time zone to UTC.
Instant instant2 = odt2.toInstant() ; // Adjust from offset to UTC.
boolean equality = instant1.equals( instant2 );
When run, we see results with a Z on the end. That means UTC, and is pronounced Zulu. And, indeed, we see these two values represent the same moment, almost 3 PM in UTC.
instant1.toString(): 2010-10-03T14:58:07Z
instant2.toString(): 2010-10-03T14:58:07Z
equality: true
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.
