From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-3.0 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 20E64211B4 for ; Sat, 12 Jan 2019 09:02:33 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 463AD121E5F; Sat, 12 Jan 2019 18:02:27 +0900 (JST) Received: from o1678916x28.outbound-mail.sendgrid.net (o1678916x28.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 1CBB8120EA0 for ; Sat, 12 Jan 2019 18:02:24 +0900 (JST) Received: by filter0168p3mdw1.sendgrid.net with SMTP id filter0168p3mdw1-18826-5C39AD1D-55 2019-01-12 09:02:21.889729321 +0000 UTC m=+32863.474248809 Received: from herokuapp.com (unknown [54.221.151.233]) by ismtpd0004p1iad1.sendgrid.net (SG) with ESMTP id Dgk9wLZOTRuu8g6XL9nwIg for ; Sat, 12 Jan 2019 09:02:21.918 +0000 (UTC) Date: Sat, 12 Jan 2019 09:02:23 +0000 (UTC) From: zverok.offline@gmail.com To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 66468 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15527 X-Redmine-Issue-Author: zverok X-Redmine-Sender: zverok X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: =?us-ascii?Q?3be0g8093pjUjT94eiCA64csFDBI=2FmHQTWm54P5gda7MNtoB4dwrLqNIF7GYBI?= =?us-ascii?Q?jsNDYYi5S9Llit6psNG1hmTMJybYpTsCaEYpQmh?= =?us-ascii?Q?yk2iPe5=2F1hMl8unR2l0D6p9ur97XGmesSC8Ek7d?= =?us-ascii?Q?zu7ysyij4gJUSOZg20Ezt3U146tMa0mcMj3s=2FWe?= =?us-ascii?Q?qINrDtIBjwY5VxhoMVXYorvwArMxHEoGwdQ=3D=3D?= X-ML-Name: ruby-core X-Mail-Count: 91034 Subject: [ruby-core:91034] [Ruby trunk Feature#15527] Redesign of timezone object requirements X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #15527 has been reported by zverok (Victor Shepelev). ---------------------------------------- Feature #15527: Redesign of timezone object requirements https://bugs.ruby-lang.org/issues/15527 * 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/