tl;dr
LocalDateTime.parse( // Parse string as a `LocalDateTime`. Lacking any time zone or offset-from-UTC means this is *not* a moment, *not* a point on the timeline.
"2018-04-25 20:09:55".replace( " " , "T" ) // Alter input to comply with ISO 8601 standard format, used by default in the *java.time* classes.
) // Returns a `LocalDateTime` object.
.atZone( // Give context and meaning to our `LocalDateTime`, to determine a point on the timeline.
ZoneId.of( "America/Montreal" ) // Always specify time zone using proper `Continent/Region` format, never 3-4 letter pseudo-zones such as `PST`, `CST`, `IST`.
) // Returns a `ZonedDateTime` object.
.toInstant() // 2018-04-26T00:09:55Z. Extract a UTC value, `Instant` object, from the `ZonedDateTime`.
.toEpochMilli() // Ask for count of milliseconds from 1970-01-01T00:00Z to this moment.
1524701395000
java.time
Alter your string input to comply with ISO 8601 standard.
String input = "2018-04-25 20:09:55".replace( " " , "T" ) ;
2018-04-25 20:09:55
Parse.
LocalDateTime ldt = LocalDateTime.parse( input ) ;
ldt.toString(): 2018-04-25T20:09:55
Apply the intended time zone, using a ZoneId
to get a ZonedDateTime
.
ZoneId z = ZoneId.of( "America/Montreal" ) ;
ZonedDateTime zdt = ldt.atZone( z ) ;
zdt.toString(): 2018-04-25T20:09:55-04:00[America/Montreal]
Extract a value in UTC, an Instant
.
Instant instant = zdt.toInstant();
instant.toString(): 2018-04-26T00:09:55Z
Get the count of milliseconds since the first moment of 1970 UTC, 1970-01-01T00:00Z.
long millis = instant.toEpochMilli() ;
1524701395000
If that input string was intended for UTC rather than a time zone (your Question is not clear in that regard), use the same ideas as above, but switch to OffsetDateTime
and ZoneOffset
in place of ZonedDateTime
and ZoneId
.
LocalDateTime.parse(
"2018-04-25 20:09:55".replace( " " , "T" )
)
.atOffset(
ZoneOffset.UTC // Using `ZoneOffset` rather than `ZoneId`. For UTC, we have the constant `ZoneOffset.UTC`.
) // Returns an `OffsetDateTime` object.
.toInstant() // 2018-04-25T20:09:55Z
.toEpochMilli()
Notice we get a different result than above, as 8 PM in UTC is a different moment than 8 PM in Montréal Québec.
1524686995000
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.