[#120073] [Ruby master Feature#20925] Allow boolean operators at beginning of line to continue previous line — "Dan0042 (Daniel DeLorme) via ruby-core" <ruby-core@...>

Issue #20925 has been reported by Dan0042 (Daniel DeLorme).

12 messages 2024/12/01

[#120141] [Ruby master Bug#20937] "can't set length of shared string" error when using OpenSSL::Cipher#update with buffer — "akiellor (Andrew Kiellor) via ruby-core" <ruby-core@...>

Issue #20937 has been reported by akiellor (Andrew Kiellor).

9 messages 2024/12/09

[#120174] [Ruby master Bug#20943] Constant defined in `Data` block — "nobu (Nobuyoshi Nakada) via ruby-core" <ruby-core@...>

Issue #20943 has been reported by nobu (Nobuyoshi Nakada).

8 messages 2024/12/11

[#120183] [Ruby master Misc#20946] Proposing tomoya ishida (@tompng) as a Ruby committer — "matsuda (Akira Matsuda) via ruby-core" <ruby-core@...>

Issue #20946 has been reported by matsuda (Akira Matsuda).

10 messages 2024/12/12

[#120189] [Ruby master Misc#20947] Propose ydah (Yudai Takada) as a Ruby committer — "yui-knk (Kaneko Yuichiro) via ruby-core" <ruby-core@...>

SXNzdWUgIzIwOTQ3IGhhcyBiZWVuIHJlcG9ydGVkIGJ5IHl1aS1rbmsgKEthbmVrbyBZdWljaGly

7 messages 2024/12/12

[#120232] [Ruby master Misc#20951] Confusing handling of timezone object's `#utc_to_local` results — "andrykonchin (Andrew Konchin) via ruby-core" <ruby-core@...>

Issue #20951 has been reported by andrykonchin (Andrew Konchin).

7 messages 2024/12/13

[#120250] [Ruby master Feature#20953] Array#fetch_values vs #values_at protocols — "zverok (Victor Shepelev) via ruby-core" <ruby-core@...>

Issue #20953 has been reported by zverok (Victor Shepelev).

11 messages 2024/12/15

[#120252] [Ruby master Bug#20955] Subtle differences with Proc#parameters for anonymous parameters — "zverok (Victor Shepelev) via ruby-core" <ruby-core@...>

SXNzdWUgIzIwOTU1IGhhcyBiZWVuIHJlcG9ydGVkIGJ5IHp2ZXJvayAoVmljdG9yIFNoZXBlbGV2

9 messages 2024/12/15

[#120283] [Ruby master Bug#20961] MMTk build on macOS missing librubygc.mmtk.bundle — "shan (Shannon Skipper) via ruby-core" <ruby-core@...>

Issue #20961 has been reported by shan (Shannon Skipper).

8 messages 2024/12/17

[#120303] [Ruby master Bug#20965] `it` vs `binding.local_variables` — "zverok (Victor Shepelev) via ruby-core" <ruby-core@...>

Issue #20965 has been reported by zverok (Victor Shepelev).

10 messages 2024/12/18

[#120315] [Ruby master Bug#20968] `Array#fetch_values` unexpected method name in stack trace — "koic (Koichi ITO) via ruby-core" <ruby-core@...>

Issue #20968 has been reported by koic (Koichi ITO).

22 messages 2024/12/19

[#120325] [Ruby master Bug#20970] `it /1/i` raises undefined method 'it' for main (NoMethodError) even if binding.local_variables includes `it` — "tompng (tomoya ishida) via ruby-core" <ruby-core@...>

Issue #20970 has been reported by tompng (tomoya ishida).

11 messages 2024/12/19

[#120335] [Ruby master Feature#20971] Deprecate `rb_path_check` — "Earlopain (Earlopain _) via ruby-core" <ruby-core@...>

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

13 messages 2024/12/19

[#120458] [Ruby master Misc#20995] exception escapes block given to IO.popen("-") in child process — "martin.dorey@... (Martin Dorey) via ruby-core" <ruby-core@...>

Issue #20995 has been reported by [email protected] (Martin Dorey).

7 messages 2024/12/31

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

From: "nobu (Nobuyoshi Nakada) via ruby-core" <ruby-core@...>
Date: 2024-12-15 08:02:49 UTC
List: ruby-core #120247
Issue #20951 has been updated by nobu (Nobuyoshi Nakada).

Tracker changed from Misc to Bug
Backport set to 3.1: REQUIRED, 3.2: REQUIRED, 3.3: REQUIRED

Moved to Bug to back port the documentation update.

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

* Author: andrykonchin (Andrew Konchin)
* Status: Feedback
* 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 -- [email protected]
 To unsubscribe send an email to [email protected]
 ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/


In This Thread