DateTimeUtils inconsistencies with default ZonedDateTime parsing.

[cerveada]

parsing in admin/src/main/scala/za/co/absa/spline/admin/DateTimeUtils.scala

ZonedDateTime.parse allows both offset and name at the same time . I think it's good idea to accept all inputs that are valid for ZonedDateTime.parse

The issue with allowing only geographical zone id is that it is ambiguous. Not unique.

2022-10-30T02:30:00[Europe/Prague] is both:
2022-10-30T02:30+02:00[Europe/Prague]
2022-10-30T02:30+01:00[Europe/Prague]

This is the day and hour of change from summer time to winter time:

val start = ZonedDateTime.parse("2022-10-30T02:30:00+02:00[Europe/Prague]")
val end = start.plusHours(1)
// start: java.time.ZonedDateTime = 2022-10-30T02:30+02:00[Europe/Prague]
// end: java.time.ZonedDateTime =   2022-10-30T02:30+01:00[Europe/Prague]

Another interesting behaviour (not so relevant for us though) is this:

val start = ZonedDateTime.parse("2022-10-30T02:30:00+02:00")
val end = start.plusHours(1)
// start: java.time.ZonedDateTime = 2022-10-30T02:30+02:00
// end: java.time.ZonedDateTime   = 2022-10-30T03:30+02:00

When no geographical zone id is provided the ZonedDateTime will stay in the same offset.

• defaultZoneId: ZoneId parameter is not use at all

[wajda]

Great point! The DST transition time is somehow slipped out of my attention. After more careful investigation I realised that my understanding of semantics of the Java's dual time zone notation (offset+ID) was incorrect. The geo ID is not simply complementary to the offset, instead it's actually the desired target representation. E.g. +07:00[Europe/Prague] will correctly compute a universal timestamp from the offset and then represent it in either +01:00 or +02:00 zone depending on whether DST is applied for the given moment in the [Europe/Prague] zone.

I'll revert the logic to use the standard Java approach.

[wajda]

Continue thinking about the best way (for the user perspective) how to handle the instant ambiguity during DST switching.
One option would be to simple parse a string in the ISO_OFFSET_DATE_TIME format. The downside of that is that the user would have to provide a time offset in all date/times he enters, which is inconvenient and on practice would never required. The offset can be derived from the provided zone ID for most times excepts for the rare case of DST switching hour. I would like to keep the offset section of the date/time format optional. In such case, the only question left is what behavior to choose if the user input hits that special case - throw an error or use an implicit assumption?
So in overall we have three possible options to choose from:

1. Require the user to always provide a zone offset. (The least convenient option for the user most of the time IMO)
2. Keep the offset optional, and if the entered time falls in the DST switching range then:
   1. Throw an error and demand the user to explicitly provide a zone offset, or
   2. Log a warning, and continue with the earlier offset in the case of an overlap, or the later one in the case of a gap.

The last option corresponds to behavior of the Java ZonedDateTime ofLocal() method without preferred offsets, and is my favorite one as well.

Regarding the consistency between different technologies, unfortunately there is no consensus. I compared the Java's ZonedDataTime behavior with the JS (vanilla Date object and two popular libraries Moment.js and Day.js) and Python (dateutil).
All mentioned JS libraries behave in exactly the same way as Java, but Python behaves in the opposite way. So 🤷‍♂️