3
public static long convertDateTimeToEpochMillis(String eventDate,String eventTime) {
    String patternMills = "yyyy-MM-dd HH:mm:ss.SSS";           
    DateTimeFormatter dtf = DateTimeFormatter.ofPattern(pattern);
    LocalDateTime localDateTime = LocalDateTime.parse(eventDate + " " + 
    eventTime, dtf);
}

This is giving a parsing exception when I am passing 2018-07-19 23:11:52.3 but parses successfully for 2018-07-19 23:11:52.312. I don't want to specify 3 different patterns for different times like yyyy-MM-dd HH:mm:ss.S,yyyy-MM-dd HH:mm:ss.SS and yyyy-MM-dd HH:mm:ss.SSS.

Can I provide a single pattern which will take up to 1/10th of a sec, 100th of a sec and millisec?

DimaSan
  • 12,264
  • 11
  • 65
  • 75
Amol Aggarwal
  • 2,674
  • 3
  • 24
  • 32
  • why should you accept the 3 format? i think that you should choose one single format, ideally `yyyy-MM-dd HH:mm:ss.SSS` and keep that in the whole application – TheOni Aug 09 '18 at 20:13
  • It gives a DateTimeParseException just as I mentioned above. – Amol Aggarwal Aug 09 '18 at 20:15
  • 2
    Check this post https://stackoverflow.com/questions/36188428/java-8-date-equivalent-to-jodas-datetimeformatterbuilder-with-multiple-parser-f – DimaSan Aug 09 '18 at 20:19
  • Check the answer at the duplicated tagged question, it looks to be a awesome solution – Marcos Vasconcelos Aug 09 '18 at 22:19
  • You are aware that your code cannot be compiled? When posting a question on Stack Overflow (not about a compiler error message) please make sure it can so we can try your code out, see it fail in the way you describe and try our suggested correction out before we post it. I get “pattern cannot be resolved to a variable” and next “This method must return a result of type long”. – Ole V.V. Aug 10 '18 at 18:30

2 Answers2

3

ISO 8601

Actually your pattern is not far from accepted by LocalDateTime.parse default pattern, using standard ISO 8601 format.

So, maybe put not a space but letter T instead will be enough for you?

Then you do not need DateTimeFormatter at all.

LocalDateTime localDateTime = LocalDateTime.parse(eventDate + "T" + 
eventTime);

It accepts any number of digits in milliseconds part, from 0 up to 9.

Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154
Vadim
  • 4,027
  • 2
  • 10
  • 26
  • ✔ Indeed, I confirmed that `LocalDateTime.parse( "2018-07-19T23:11:52.3" ).toString()` works, yielding `2018-07-19T23:11:52.300` in Java 10.0.1. – Basil Bourque Aug 09 '18 at 22:05
2

You can just choose a pattern with three SSS as default

String patternMills = "yyyy-MM-dd HH:mm:ss.SSS";

and fulfill right side of your date with zeros when necessary

String eventDate = "2018-07-19 23:11:52.3";
String millis = eventDate.substring(eventDate.lastIndexOf('.')+1);

if(millis.length() < 3) 
    eventDate += Stream.generate(() -> "0").limit(3 - millis.length()).collect(Collectors.joining(""));

or use nice apache method:

StringUtils.rightPad(eventDate, 23, '0'); // 23 is string length for "yyyy-MM-dd HH:mm:ss.SSS" pattern

Anyway you can also add some validation to check the rest part of the date string

m.antkowicz
  • 13,268
  • 18
  • 37
  • 1
    I don't know this answer is correct but instead of `split` use `eventDate.substring(eventDate.lastIndexOf(".")+1)` – Hadi J Aug 09 '18 at 20:27
  • @HadiJ actually edited my answer - thx ;) – m.antkowicz Aug 09 '18 at 20:28
  • 1
    Note that the OP have to decide whether the `3` in `2018-07-19 23:11:52.3` means 3 milliseconds or 300 miliseconds, and right or left pad accordingly. – nos Aug 09 '18 at 20:39
  • 1
    @nos you are quite not right. 23:11:52.3 is always 300 ms. and 3 milliseconds will be 23:11:52.003 – Vadim Aug 09 '18 at 20:48
  • @Vadim That depend on your input. I've parsed files where the .3 means 300 miliseconds. And even files where the last .3 meant 1/3 of a second. – nos Aug 09 '18 at 21:49
  • 1
    @nos - are you kidding? how about Math basics? what milli- stands for in "millisecond"? and 0.3 does never mean 1/3 ... except somebody with no basic math knowledge built that file :-) – Vadim Aug 10 '18 at 15:57
  • It’s a convoluted solution IMHO (though it should work). I wouldn’t want to end up maintaining this code, and would be likely to rewrite it if I did. – Ole V.V. Aug 10 '18 at 18:24