DateTime.parseDateTimeString will create a non-sensical timestamp for 14-character epoch-like values that use more than one period

[ctiwald]

Noticed this while mucking around with a tool that fronts the TSDB API (i.e. I was trying to clone TSDB's timestamp validation):

https://github.com/OpenTSDB/opentsdb/blob/master/src/utils/DateTime.java#L124-L129

That logic will incorrectly pass a 14-character timestamp that contains a . at the 10th character, but also contains another .:

1234567890.2.4

for example.

Notably, this will convert to "123456789024" on the '.' replace, rather than erroring as it should.

I'm happy to submit a patch for this, but thought I'd check first to see how much you all care :-).

[manolama]

Ah good catch, if you'd like submit a PR I'll get it merged in. Thanks!

[johann8384]

Fixed in #739

[ctiwald]

Errrr... am I misunderstanding the fix or does it only address cases where there are exactly two .? You could have three, or four, or...

[johann8384]

You're right, I was in a rush. Other forms of malformed timestamps could still slip through the mix.

[johann8384]

As soon as Travis is done I'll merge the fixed-fix. #742