From: naruse@... Date: 2019-01-13T09:53:40+00:00 Subject: [ruby-core:91064] [Ruby trunk Feature#15527] Redesign of timezone object requirements Issue #15527 has been updated by naruse (Yui NARUSE). Sounds interesting, but `zone.utc_offset(time)` can only be a partial alternative of `utc_to_local` with using `gmtime(3). Note that a timezone system requires two API. One is an API which converts from [year, month, day, hour, minute, second] to epoch. And another is an API which converts from epoch to [year, month, day, hour, minute, second, isdst, zonestr]. ---------------------------------------- Feature #15527: Redesign of timezone object requirements https://bugs.ruby-lang.org/issues/15527#change-76283 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- In #14850, there was timezone support introduced, there were pretty specific requirements for the Timezone object: > A timezone argument must have `local_to_utc` and `utc_to_local` methods... The `local_to_utc` method should convert a `Time`-like object from the timezone to UTC, and `utc_to_local` is the opposite. ... The zone of the result is just ignored. I understand this requirements were modelled after existing TZInfo gem, but the problem with them are: * they are too ad-hoc (in fact, return values of methods aren't used as a "Time object", but as a tuple of time components) * they belong to outdated tzinfo API (ignoring of offsets is due to support of **Ruby 1.8**, which didn't allowed constructing `Time` object with arbitrary offset, see [discussion](https://github.com/tzinfo/tzinfo/issues/49)), recent [release](https://github.com/tzinfo/tzinfo/pull/52) introduces also `#to_local`, which returns `Time` with proper offset. The latter is a bit of time paradox: Ruby **2.6** new feature is designed after the library which works this way to support Ruby **1.8** :) The bad thing is, this approach somehow "codifies" outdated API (so in future, any alternative timezone library should support pretty arbitrary API). I believe, that in order to do everything that `Time` needs, _timezone_ object should be able to answer exactly one question: "what offset from UTC is/was observed in this timezone at particular date". In fact, TZInfo **has** the [API](https://www.rubydoc.info/gems/tzinfo/TZInfo/Timezone#observed_utc_offset-instance_method) for this: ```ruby tz = TZInfo::Timezone.get('America/New_York') # => # tz.utc_offset(Time.now) # => -18000 ``` If I understand correctly, this requirement ("A timezone argument must have `#utc_offset(at_time)`") will greatly simplify the implementation of `Time`, while also being compatible with `TZInfo` gem and much more explainable. With this requirement, alternative implementations could now be much simpler and focus only on "find the proper timezone/period/offset", omitting any (hard) details of deconstructing/constructing Time objects. -- https://bugs.ruby-lang.org/ Unsubscribe: