I am wondering if there is a way to get current milliseconds since 1-1-1970 (epoch) using the new LocalDate, LocalTime or LocalDateTime classes of Java 8.
The known way is below:
long currentMilliseconds = new Date().getTime(); or
long currentMilliseconds = System.currentTimeMillis(); I'm not entirely sure what you mean by "current milliseconds" but I'll assume it's the number of milliseconds since the "epoch," namely midnight, January 1, 1970 UTC.
If you want to find the number of milliseconds since the epoch right now, then use System.currentTimeMillis() as Anubian Noob has pointed out. If so, there's no reason to use any of the new java.time APIs to do this.
However, maybe you already have a LocalDateTime or similar object from somewhere and you want to convert it to milliseconds since the epoch. It's not possible to do that directly, since the LocalDateTime family of objects has no notion of what time zone they're in. Thus time zone information needs to be supplied to find the time relative to the epoch, which is in UTC.
Suppose you have a LocalDateTime like this:
LocalDateTime ldt = LocalDateTime.of(2014, 5, 29, 18, 41, 16); You need to apply the time zone information, giving a ZonedDateTime. I'm in the same time zone as Los Angeles, so I'd do something like this:
ZonedDateTime zdt = ldt.atZone(ZoneId.of("America/Los_Angeles")); Of course, this makes assumptions about the time zone. And there are edge cases that can occur, for example, if the local time happens to name a time near the Daylight Saving Time (Summer Time) transition. Let's set these aside, but you should be aware that these cases exist.
Anyway, if you can get a valid ZonedDateTime, you can convert this to the number of milliseconds since the epoch, like so:
long millis = zdt.toInstant().toEpochMilli(); 
getEpochSecond method (via ChronoZonedDateTime default). No need for the Instant.
ZonedDateTime also has Instants getNano method, so wouldn't you be able to just replace inst with zdt in your example?
What I do so I don't specify a time zone is,
System.out.println("ldt " + LocalDateTime.now().atZone(ZoneId.systemDefault()).toInstant().toEpochMilli()); System.out.println("ctm " + System.currentTimeMillis()); gives
ldt 1424812121078 ctm 1424812121281 As you can see the numbers are the same except for a small execution time.
Just in case you don't like System.currentTimeMillis, use Instant.now().toEpochMilli()
System.out.println("ctm " + System.currentTimeMillis()); with System.out.println("ldt " + LocalDateTime.now().atZone(ZoneId.systemDefault()).toInstant().toEpochMilli()); i.e. execute the exact same statement twice and you will still see the difference equal to the no. of milliseconds elapsed since the last execution of the same statement.Since Java 8 you can call java.time.Instant.toEpochMilli().
For example the call
final long currentTimeJava8 = Instant.now().toEpochMilli(); gives you the same results as
final long currentTimeJava1 = System.currentTimeMillis(); 
To avoid ZoneId you can do:
LocalDateTime date = LocalDateTime.of(1970, 1, 1, 0, 0); System.out.println("Initial Epoch (TimeInMillis): " + date.toInstant(ZoneOffset.ofTotalSeconds(0)).toEpochMilli()); Getting 0 as value, that's right!
ZoneOffset.ofTotalSeconds(0) it is the same as ZoneOffset.UTC
ZoneOffset is a subclass of ZoneId, so I wouldn’t exactly say you have avoided it, but as long as you’re happy…ZoneId?You can use java.sql.Timestamp also to get milliseconds.
LocalDateTime now = LocalDateTime.now(); long milliSeconds = Timestamp.valueOf(now).getTime(); System.out.println("MilliSeconds: "+milliSeconds); 
Timestamp class is long outdated and filled with design problems, so I’d rather avoid it, especially when we can use the classes from java.time like LocalDateTime.
Timestamp, Can you share some article on that? It helps me to avoid using Timestamp from my code as well. Thanks!Date but often cannot be handled as a Date. Most of the methods inherited from Date and one constructor are deprecated. Its toString method uses the JVM’s time zone, which confuses many since the same Timestamp is printed differently on different computers (example).
LocalDate.of(year, month, day)
To get the current time in milliseconds (since the epoch), use System.currentTimeMillis().
You can try this:
long diff = LocalDateTime.now().atZone(ZoneOffset.UTC).toInstant().toEpochMilli(); 
LocalDateTime without local offset (always use UTC only) then it's better to just use Instant for REST, Websockets and other logic, and then you can pass that Instant to ZonedDateTime when you want to format date time for UI with local offset. In this case you don't use LocalDateTime at allLocalDateTime.now().toInstant(OffsetDateTime.now().offset) is easierWhy didn't anyone mentioned the method LocalDateTime.toEpochSecond():
LocalDateTime localDateTime = ... // whatever e.g. LocalDateTime.now() long time2epoch = localDateTime.toEpochSecond(ZoneOffset.UTC); This seems way shorter that many suggested answers above...
toEpochMilli method, taken into account the fact that you can specify even nanoseconds in LocalDateTime: there is a method LocalDateTime.of(int year, int month, int dayOfMonth, int hour, int minute, int second, int nanoOfSecond).I think this is more simpler:
ZonedDateTime zdt = ZonedDateTime.of(LocalDateTime.now(), ZoneId.systemDefault()); Assert.assertEquals(System.currentTimeMillis(), zdt.toInstant().toEpochMilli()); get the millis like System.currentTimeMillis() (from UTC).
In case of LocalDate, you can use the toEpochDay() method. It returns the number of days since 01/01/1970. That number then can be easily converted to milliseconds:
long dateInMillis = TimeUnit.DAYS.toMillis(myLocalDate.toEpochDay()); In case of LocalDateTime, you can use the toEpochSecond() method. It returns the number of seconds since 01/01/1970. That number then can be converted to milliseconds, too:
long dateTimeInMillis = TimeUnit.SECONDS.toMillis(myLocalDateTime.toEpochSecond()); 
toEpochDay
For LocalDateTime I do it this way:
LocalDateTime.of(2021,3,18,7,17,24,341000000) .toInstant(OffsetDateTime.now().getOffset()) .toEpochMilli() If you have a Java 8 Clock, then you can use clock.millis() (although it recommends you use clock.instant() to get a Java 8 Instant, as it's more accurate).
Why would you use a Java 8 clock? So in your DI framework you can create a Clock bean:
@Bean public Clock getClock() { return Clock.systemUTC(); } and then in your tests you can easily Mock it:
@MockBean private Clock clock; or you can have a different bean:
@Bean public Clock getClock() { return Clock.fixed(instant, zone); } which helps with tests that assert dates and times immeasurably.
Date and time as String to Long (millis):
String dateTimeString = "2020-12-12T14:34:18.000Z"; DateTimeFormatter formatter = DateTimeFormatter .ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'", Locale.ENGLISH); LocalDateTime localDateTime = LocalDateTime .parse(dateTimeString, formatter); Long dateTimeMillis = localDateTime .atZone(ZoneId.systemDefault()) .toInstant() .toEpochMilli(); 
default LocalDateTime getDateFromLong(long timestamp) { try { return LocalDateTime.ofInstant(Instant.ofEpochMilli(timestamp), ZoneOffset.UTC); } catch (DateTimeException tdException) { // throw new } } default Long getLongFromDateTime(LocalDateTime dateTime) { return dateTime.atOffset(ZoneOffset.UTC).toInstant().toEpochMilli(); } My simple code for resolve parsing ISO date format with offset and without them.
In second part (in else condition) - the way How I solved the problem with parsing time of era and time of day into Milliseconds.
public static long parseISO8601WithCurrentOffset(String iso8601String) { TemporalAccessor temporalAccessor = DateTimeFormatter.ISO_DATE_TIME.parse(iso8601String); if (temporalAccessor.isSupported(ChronoField.OFFSET_SECONDS)) { // 2024-07-01T15:30:45.102+03:00 long inputTime = Instant.from(temporalAccessor).toEpochMilli(); long inputOffset = TimeUnit.SECONDS.toMillis(temporalAccessor.getLong(ChronoField.OFFSET_SECONDS)); long finalTime = inputTime - inputOffset; return finalTime + TimeUnit.SECONDS.toMillis(TimeFieldUtils.getServerOffset().getTotalSeconds()); } else { // 2024-07-01T15:30:45.102 // 23:59:59.102_000000 LocalTime timeOfDay = temporalAccessor.query(TemporalQueries.localTime()); // 01.07.2024 LocalDate timeOfEra = temporalAccessor.query(TemporalQueries.localDate()); long msOfDay = timeOfDay.getLong(ChronoField.MILLI_OF_DAY); long msOfEra = TimeUnit.DAYS.toMillis(LocalDate.EPOCH.until(timeOfEra, ChronoUnit.DAYS)); return msOfEra + msOfDay; } } It also can be used as a creating and returing date :\ But in this case - use a Calendar, it more easely to understand.
LocalTime timeOfDay = LocalTime.of(10, 10, 10); LocalDate timeOfEra = LocalDate.of(2025, 10, 2); return TimeUnit.DAYS.toMillis(LocalDate.EPOCH.until(timeOfEra, ChronoUnit.DAYS)) + timeOfDay.getLong(ChronoField.MILLI_OF_DAY); Calendar calendar = Calendar.getInstance(); calendar.set(Calendar.ZONE_OFFSET, (int) TimeUnit.SECONDS.toMillis(OffsetDateTime.now().getOffset().getTotalSeconds())); calendar.set(Calendar.HOUR, 10); calendar.set(Calendar.MINUTE, 10); calendar.set(Calendar.SECOND, 10); calendar.set(Calendar.YEAR, 2025); calendar.set(Calendar.MONTH, 10); calendar.set(Calendar.DAY_OF_MONTH, 2); return calendar.getTimeInMillis(); 
Calendar class should not be used anymore (one of many reason: if you compare the result of your last example with the one in the second to last: 31 days [in milliseconds]... since not doing calendar.set(Calendar.MONTH, Calendar.OCTOBER))
Instant.now().toEpochMilli() solves the Question. If ISO 8601 string input were involved: Instant.parse( input ).toEpochMilli().
Simplest conversion:
Instant.from(localDateTime).toEpochMilli() SORRY this does not work and gies the following error:
"Unsupported field: InstantSeconds", " java.base/java.time.LocalDate.get0(LocalDate.java:708)", " java.base/java.time.LocalDate.getLong(LocalDate.java:687)", " java.base/java.time.LocalDateTime.getLong(LocalDateTime.java:720)", " java.base/java.time.Instant.from(Instant.java:373)", " com.capitalone.rupol.ruleengine.util.LocalDateSerializer.serialize(LocalDateSerializer.java:25)", "Unable to obtain Instant from TemporalAccessor: 2024-02-03T00:00 of type java.time.LocalDateTime", " java.base/java.time.Instant.from(Instant.java:378)", " com.capitalone.rupol.ruleengine.util.LocalDateSerializer.serialize(LocalDateSerializer.java:25)", " com.capitalone.rupol.ruleengine.util.LocalDateSerializer.serialize(LocalDateSerializer.java:11)", " com.fasterxml.jackson.databind.ser.std.MapSerializer.serializeOptionalFields(MapSerializer.java:869)", " com.fasterxml.jackson.databind.ser.std.MapSerializer.serializeWithoutTypeInfo(MapSerializer.java:760)", The LocalDateTime does not carry a time zone. The Instant does not carry a time zone. Strangely, many of the other conversions require specifying a time zone that you don't need. This avoids using a time zone offset at any step, and converts internally from millis to millis.
It is strange that the LocalDateTime does not offer a conversion to Instant, since both LocalDateTime and Instant do not involve any representation of a time zone, but this factory method does the job.
Instant class represents a moment, a point on the timeline, as seen in UTC, an offset of zero hours-minutes-seconds. In contrast, the LocalDateTime class has no concept of time zone or offset, but is merely a date with time-of-day, nothing more. So there is no logic is trying to convert between the two. One is a moment, the other is not.
System.currentTimeMillis()?currentTimeMilliswould be irrelevant in that context. Think Calendar + Wall-clock with really good precision, and no concerns about time zones and locality. So there's no way to get back to "UTC Time" from a LocalTime