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:
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?
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:
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?