DateTimeType spec fix (#340)

The case of `DateTimeType.parse("00:00+1000")` is parsed by Time.parse
in DSL.try_parse_time_like, which takes into account the current time
and the system time zone in interpreting the given "time+timezone"
string.

This is why it has been intermittent in the past: depending on the time
the spec was running, and the system time zone of the machine running
the spec, the resulting _date_ could be either today or yesterday
whereas the previous spec was pinning the date to today's date.

Here's a demonstration, notice the date in the last example:
```
irb(main):047> Time.now
=> 2024-09-17 10:16:27.302101 +1000
irb(main):048> Time.now.utc
=> 2024-09-17 00:16:33.278331 UTC
irb(main):049> Time.parse("0:00+00:00")
=> 2024-09-17 00:00:00 +0000
irb(main):050> Time.parse("0:00-00:18")
=> 2024-09-16 00:00:00 -0018
```

The solution in this PR is to simply compare the result against
Time.parse so we should get the exact same result since they're using
the same parser (and hence parsing logic) to come up with whatever date
it is.

In practice, parsing time+timezone without a date is perhaps a rare
case?

Signed-off-by: Jimmy Tanagra <[email protected]>

spec/openhab/core/types/date_time_type_spec.rb

@@ -79,10 +79,7 @@
     end
 
     it "parses time only strings with a timezone" do
-      zone_id = ZoneId.of("+1000")
-      date_time_type = DateTimeType.parse("3:30+1000").to_zone(zone_id)
-      date_time = ZonedDateTime.now.with(LocalTime.parse("3:30")).with_zone_same_local(zone_id)
-      expect(date_time_type).to eq date_time
+      expect(DateTimeType.parse("3:30-1000")).to eq Time.parse("3:30-1000").to_zoned_date_time
     end
   end
 end