I'm trying to convert date time string like 25-05-2022 05:40:51 to nanoseconds (1653457251000000000) since epoch in Java
-
1In which time zone is that date and time? – Ole V.V. May 25 '22 at 14:06
-
1Did you try your search engine? Does this answer your question? [How to convert time stamp to epoch/nanoseconds in Java?](https://stackoverflow.com/questions/49565223/how-to-convert-time-stamp-to-epoch-nanoseconds-in-java) – Ole V.V. May 25 '22 at 14:22
2 Answers
I think you will have to calculate the nanos (as already mentioned in an answer to a similar question), there seems to be no possibility of directly deriving that value from an Instant
or any equivalent class in java.time
. You will have to explicitly provide a time zone (java.time.ZoneId
) if you want a reliable solution that does not depend on the configuration of the JVM the code is executed on.
Steps you can perform:
- define a formatter and use it to parse the
String
, which should result in aLocalDateTime
because your input does not contain a time zone or offset - provide the time zone and use it together with the
LocalDateTime
producing aZonedDateTime
- get the
Instant
defined by theZonedDateTime
and use its epoch millis value in order to calculate the nanos
Here's a demo that shows you how a time zone matters in your case:
Different ones are likely to produce different values, so better explicitly define one in your code (long version for readability).
public static void main(String[] args) {
// define the expected nano value
long expectedNanos = 1653457251000000000L;
// your example input (no time zone or offset given!)
String input = "25-05-2022 05:40:51";
// create a formatter to be used as parser for the input
DateTimeFormatter dtf = DateTimeFormatter.ofPattern("dd-MM-uuuu HH:mm:ss");
// parse it to have a LocalDateTime
LocalDateTime localDateTime = LocalDateTime.parse(input, dtf);
// create two zones in order to find out how the zones matter here
ZoneId utc = ZoneId.of("UTC");
ZoneId kolkata = ZoneId.of("Asia/Kolkata");
// apply each zone to the LocalDateTime and create two ZonedDateTimes
ZonedDateTime timeInUtc = localDateTime.atZone(utc);
ZonedDateTime timeInKolkata = localDateTime.atZone(kolkata);
// Instants can be derived from ZonedDateTimes, do so twice here
Instant utcInstant = timeInUtc.toInstant();
Instant kolkataInstant = timeInKolkata.toInstant();
// provide a factor for a full nano calculation
long nanoFactor = 1000000L;
// calculate the nanos
long nanosInUtc = utcInstant.toEpochMilli() * nanoFactor + utcInstant.getNano();
long nanosInKolkata = kolkataInstant.toEpochMilli() * nanoFactor + kolkataInstant.getNano();
// produce some meaningful output (expected value or not?)
String utcOutput = String.format("UTC: %-40s ––> %d => %s",
timeInUtc, nanosInUtc,
(expectedNanos == nanosInUtc) ? "expected" : "unexpected");
String kolkataOutput = String.format("Kolkata: %-40s ––> %d => %s",
timeInKolkata, nanosInKolkata,
(expectedNanos == nanosInKolkata) ? "expected" : "unexpected");
// and actually print that output
System.out.println(utcOutput);
System.out.println(kolkataOutput);
}
This will result in the following lines pointing out the importance of the time zone:
UTC: 2022-05-25T05:40:51Z[UTC] ––> 1653457251000000000 => expected
Kolkata: 2022-05-25T05:40:51+05:30[Asia/Kolkata] ––> 1653437451000000000 => unexpected
As you can see, the time of day as well as the date is the same (in your input and both output values), but the offset from UTC is different (Z is an offset of 00:00
hours). That will of course result in different Instant
s.
Given your expected result, you should provide UTC as zone.

- 17,687
- 10
- 38
- 51
-
1Good answer with good explanation and good awareness of time zone. Thanks. For calculating the nanos I think I’d be lazy and just do `ChronoUnit.NANOS.between(Instant.EPOCH, timeInUtc)`. Since java.time already knows how to convert `timeInUtc` to an `Instant`, this works. `between()` also detects `long` overflow. – Ole V.V. May 25 '22 at 14:42
-
1*Given your expected result, you should provide UTC as zone.* Given the expected result it *is* also possible, though unlikely, that the OP intended Africa/Ouagadougou, America/Danmarkshavn, Atlantic/Reykjavik, Atlantic/Azores or some other time zone. Most likely you are correct, and the OP knows best. – Ole V.V. May 25 '22 at 14:48
// Use any online Java Compiler like Programiz to test this
import java.util.Date;
import java.text.SimpleDateFormat;
import java.time.Instant;
import java.util.concurrent.TimeUnit;
class HelloWorld {
public static void main(String[] args) throws Exception{
String sDate6 = "25-05-2022 05:40:51";
SimpleDateFormat formatter6=new SimpleDateFormat("dd-MM-yyyy HH:mm:ss");
Date date6=formatter6.parse(sDate6);
System.out.println("Hello" + date6 );
Instant instant = date6.toInstant();
System.out.println("\n seconds: " + instant.getEpochSecond());
System.out.println("\n remaining ns: " + instant.getNano());
System.out.println("\n ns since epoch: " +(TimeUnit.SECONDS.toNanos(instant.getEpochSecond()) + instant.getNano()));
}
}

- 123
- 4
- 13
-
2Why use SimpleDateFormat to turn convert it to an Instant? Why not use DateTimeFormatter directly? – MadProgrammer May 25 '22 at 07:10
-
1Seriously, please don't mix those two APIs, either stick to `java.time` or use the outdated `Date` and `SimpleDateFormat`… – deHaar May 25 '22 at 07:24
-
3Wait… Is this actually an answer or your code effort that should have been in your question? – deHaar May 25 '22 at 07:54
-
1I strongly recommend you don’t use `SimpleDateFormat`. Since you are using java.time, also use its `DateTimeFormatter` class for parsing. – Ole V.V. May 25 '22 at 14:09