Time.new(string, in: ...) raises TypeError on the third call at a call site (JIT only)

[headius]

Clone of #9531 for 10.1.

3.times { Time.new("2023-05-08 10:21:21", in: "UTC") }

TypeError: no implicit conversion of Hash into Integer
  initialize at org/jruby/RubyTime.java:1867
  initialize at org/jruby/RubyTime.java:1886
  initialize at org/jruby/RubyTime.java:1841

The first two calls succeed and return the correct Time; the third call at the same call site raises. The count is per call site, not per process.

Environment

jruby 10.1.0.0 (4.0.0) 2026-04-21 ffffffffff OpenJDK 64-Bit Server VM 26.0.1 on 26.0.1 +indy +jit [arm64-darwin]

Narrowing

• Interpreter is clean: jruby -X-C runs the same loop without error, so this looks like the compiled/specialized call-site path rather than the Time logic itself.
• The string form plus the in: keyword is the trigger:
  • Time.new("2023-05-08 10:21:21.561670") (no in:) — clean over many iterations
  • Time.new(2023, 5, 8, 10, 21, 21, "UTC") (positional) — clean
  • in: "+00:00" fails the same way as in: "UTC"
• The argument values don't matter: passing a different string on each iteration still fails on the third call.
• Expected (CRuby 3.2+ semantics): all iterations return 2023-05-08 10:21:21 UTC.

Impact

Rails 8's ActiveModel timestamp cast (fast_string_to_time) is exactly ::Time.new(string, in: "UTC"), so on Rails 8 + JRuby every datetime column read hits this once the call site warms up: the first couple of records deserialize fine, then every subsequent read raises TypeError. (Found while benchmarking a Rails 8.0.5 app on JRuby; rescue ArgumentError in Rails doesn't catch it since this is TypeError.)

Possibly adjacent to the Time.new timezone work tracked in #8736, but this one is call-count-dependent rather than a semantics gap.