Reproduction Steps
Call DateTime.fromLocalTime with the milliseconds argument set to a nonzero value and compare it to a different call to DateTime.fromLocalTime with the milliseconds argument set to zero while all other arguments stay the same. This bug doesn’t seem to occur when local time is the same as universal time.
Expected Behavior
I expect the milliseconds argument to always be used in DateTime.fromLocalTime, the resulting DateTime object will be correctly created using all arguments.
Actual Behavior
The milliseconds argument is ignored when local time is not the same as universal time:
When local time is the same as universal time, the milliseconds argument is used correctly:
Workaround
This issue can be worked around by calling DateTime.fromLocalTime without the milliseconds argument, and adding the milliseconds argument to the unix timestamp: DateTime.fromUnixTimestampMillis(DateTime.fromLocalTime(year,month,day,hour,minute,second).UnixTimestampMillis+millisecond)
Issue Area: Engine
Issue Type: Other
Impact: Low
Frequency: Rarely