Allow parsing timezone without fully provided time

[pgomulka]

strict_date_optional_time in Joda allowed to provide just a timezone without fully provided time. So dates like 2018-01-01T00+01 , 2018-01-01T00:00+01 , 2018-01-01T00:00:00+01 , 2018-01-01T00:00:00.000+01 were allowed.
This should be fixed in java.time implementation too.
However, Joda was incorrectly parsing 2018-01-01T+01 when no time part was provided. It is because +01 which should be considered an offset, is parsed as a signed hour part.
java.time implementation does not suffer from this and correctly parses this date. We are not allowing this though, as this is not allowed be iso8601 spec.
In essence this PR is only fixing parsing for 2018-01-01T00+01. Other formats were allowed already.
closes #49351

[elasticmachine]

Pinging @elastic/es-core-infra (:Core/Infra/Core)

[rjernst]

I'm not sure this is something we want to do. I don't think ISO 8601 allows for timezone without a time. I thought we were moving towards deprecating joda specific functionality? This especially seems a weird feature to support since based on your description it appears joda doesn't actually support this as it intended, hence why the dueling tests are commented out.

[mark-vieira]

FYI, you'll need to merge in the latest changes from master to fix these CI failure due to the new Java 13 build requirement.

[pgomulka]

@elasticmachine update branch

[pugnascotia]

Do we perhaps want a comment here about Joda as well?

[jamshid]

Thank you for fixing this!
Both 2016-11-30T12+01 and 2016-11-30T+01 were parsed as valid dates with 6.8.x.
But only the former will continue to parse in 7.6.0?

[pgomulka]

@jamshid as per my comment here https://github.com/elastic/elasticsearch/pull/50178/files#diff-216a9f905247015f48298c3b6b1bb3a0R68
our strict_date_optional_time in Joda incorrectly parses 2016-11-30T+01 as 2016-11-30T01:00:00Z when it should be 2016-11-29T23:00:00Z. So even though you were not getting any exceptions, it was parsing these dates incorrectly
date_optional_time does not suffer from this

please bear in mind, I need to confirm with ISO8601 if this should be merged at all.

[pgomulka]

@elasticmachine update branch

[pgomulka]

@rjernst it looks that this should indeed be allowed as ISO/WD 8601-1 allows time representation with reduced accuracy
draft iso spec:
http://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_iso_wd_8601-1_2016-02-16.pdf
points 4.2.2.3 - 4.2.5.2.

[pgomulka]

I actually re-read the spec and it looks that timezone can only by applied with time.

Expressions	 of	 the	 difference	 between	 local	 time	 and	 UTC	 of	 day	 are	 a	 component	 in	 the	
representations	defined	in	4.2.5.2;	they	shall	not	be	used	as	self-standing	expressions.

where

4.2.5.2 Local	time	and	the	difference	from	UTC

allows reduced accuracy of local time. This is defined in

4.2.2.3 Representations	with	reduced	accuracy

and allows only hh:mm or hh

Therefore 2016-11-30T12+01 is correct
but 2016-11-30T+01 is incorrect.
You can also see a discussion here https://stackoverflow.com/questions/52215961/how-can-i-write-an-iso-8601-date-with-a-timezone-but-no-time-component
I understand this was parsed successfully in 6.8 but I would consider this to be a bug in joda.

[pgomulka]

@elasticmachine update branch