[#121215] [Ruby master Bug#21166] Fiber Scheduler is unable to be interrupted by `IO#close`. — "ioquatix (Samuel Williams) via ruby-core" <ruby-core@...>

Issue #21166 has been reported by ioquatix (Samuel Williams).

13 messages 2025/03/02

[#121222] [Ruby master Bug#21167] Visual Studio 2022 17.13.x couldn't build ruby.exe — "hsbt (Hiroshi SHIBATA) via ruby-core" <ruby-core@...>

Issue #21167 has been reported by hsbt (Hiroshi SHIBATA).

8 messages 2025/03/03

[#121234] [Ruby master Bug#21168] Prism doesn't require argument parentheses (in some cases) when a block is present but parse.y does — "Earlopain (Earlopain _) via ruby-core" <ruby-core@...>

Issue #21168 has been reported by Earlopain (Earlopain _).

8 messages 2025/03/04

[#121389] [Ruby Bug#21187] Strings concatenated with `\` getting frozen with literal hashes (PRISM only) — LocoDelAssembly via ruby-core <ruby-core@...>

Issue #21187 has been reported by LocoDelAssembly (Hern=E1n Pereira).

12 messages 2025/03/17

[#121413] [Ruby Bug#21193] Inherited callback returns `nil` for `Object.const_source_location` — "eileencodes (Eileen Uchitelle) via ruby-core" <ruby-core@...>

Issue #21193 has been reported by eileencodes (Eileen Uchitelle).

15 messages 2025/03/20

[#121451] [Ruby Bug#21201] Performance regression when defining methods inside `refine` blocks — "alpaca-tc (Hiroyuki Ishii) via ruby-core" <ruby-core@...>

Issue #21201 has been reported by alpaca-tc (Hiroyuki Ishii).

8 messages 2025/03/27

[ruby-core:121264] [Ruby master Bug#20951] Confusing handling of timezone object's `#utc_to_local` results

From: "nagachika (Tomoyuki Chikanaga) via ruby-core" <ruby-core@...>
Date: 2025-03-08 07:53:40 UTC
List: ruby-core #121264
Issue #20951 has been updated by nagachika (Tomoyuki Chikanaga).

Status changed from Feedback to Closed

Moved to "Closed" status to trigger backport.

----------------------------------------
Bug #20951: Confusing handling of timezone object's `#utc_to_local` results
https://bugs.ruby-lang.org/issues/20951#change-112219

* Author: andrykonchin (Andrew Konchin)
* Status: Closed
* Backport: 3.1: REQUIRED, 3.2: REQUIRED, 3.3: REQUIRED
----------------------------------------
I am looking into the timezone object feature (that is supported by various Time class methods) now and I am confused by the current implementation. Specifically, how a time-like object **that is not inherited from the Time class** is handled. A time-like object is returned for instance from the timezone object's `#utc_to_local` method.

The documentation states that:

> A Time-like object is a container object capable of interfacing with timezone libraries for timezone conversion.

Also

> The zone value may be an object responding to certain timezone methods, an instance of Timezone and TZInfo for example.

And indeed the `TZInfo::Timezone` class works as expected.

But when I try to use for time-like objects a brand new class not inherited from Time - it works incorrectly. Let's consider an example with `TZInfo::Timezone`:

```ruby
require 'tzinfo'

zone = TZInfo::Timezone.get("Europe/Kiev") # UTC+2
time = Time.now.utc

puts time.to_i                    # 1734107333

puts Time.now(in: zone)           # 2024-12-13 18:28:53 +0200
puts zone.utc_to_local(time)      # 2024-12-13 18:28:53 +0200
puts zone.utc_to_local(time).to_i # 1734107333
```

And now an example with a brand new class.

I make an assumption, that as far as `zone.utc_to_local(time).to_i` doesn't change Unix timestamp (it equals `time.to_i`, that's 1734107333), so in a new class also `#utc_to_local` should return not modified value too.

```ruby
TimeObj = Struct.new(:year, :mon, :mday, :hour, :min, :sec, :isdst, :to_i)

zone_obj = Object.new
def zone_obj.utc_to_local(t)
  TimeObj.new(t.year, t.mon, t.mday, t.hour + 2, t.min, t.sec, t.isdst, t.to_i)  # <=== adjust hours (`hours + 2`) to match "Europe/Kiev" timezone (that's UTC+2)
end
```

Unfortunately it produces incorrect result:

```ruby
puts Time.now(in: zone_obj)           # 2024-12-13 18:28:53 +0000    <====== wrong UTC offset
puts zone_obj.utc_to_local(time)      # #<struct TimeObj year=2024, mon=12, mday=13, hour=18, min=28, sec=53, isdst=false, to_i=1734107333>
puts zone_obj.utc_to_local(time).to_i # 1734107333     <===== the same Unix timestamp

```

So now result time object has wrong utc offset - `+0000` instead of `+0200`.

Okey, so probably Unix timestamp should be adjusted as well. Let's check:

```ruby
def zone_obj.utc_to_local(t)
  TimeObj.new(t.year, t.mon, t.mday, t.hour + 2, t.min, t.sec, t.isdst, t.to_i + 2 * 60 * 60) # <===== adjust #to_i as well so it returns timestamp + 2 hours
end

puts Time.now(in: zone_obj)           # 2024-12-13 18:28:53 +0200     <======= correct UTC offset
puts zone_obj.utc_to_local(time)      # #<struct TimeObj year=2024, mon=12, mday=13, hour=18, min=28, sec=53, isdst=false, to_i=1734114533>
puts zone_obj.utc_to_local(time).to_i # 1734114533     <====== different Unix timestamp
```

Now we have correct UTC offset `+0200` despite `zone_obj.utc_to_local(time).to_i` returns not original offset but an adjusted one.

I assume the difference is caused by a special treatment of time-like object inherited from the Time class. So its `utc_offset` property is used only. But for all the other classes the `#to_i` is used instead.

```ruby
zone.utc_to_local(time).class.ancestors
# => [TZInfo::TimeWithOffset, TZInfo::WithOffset, Time, Comparable, Object, PP::ObjectMixin, Kernel, BasicObject]
```

This difference is confusing so I think it makes sense either to document it (I mean to document that `#to_i` should return adjusted value for non-related to Time classes) in case it's intentional or to change behaviour for non-related to Time classes and rely not on `#to_i` to calculate UTC offset but on difference in `sec`/`min`/`hours` values otherwise.



-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/


In This Thread