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.4 required=3.0 tests=AWL,BAYES_00, 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 D82B1211B4 for ; Sun, 13 Jan 2019 09:53:49 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id A1C48121C45; Sun, 13 Jan 2019 18:53:45 +0900 (JST) Received: from o1678948x4.outbound-mail.sendgrid.net (o1678948x4.outbound-mail.sendgrid.net [167.89.48.4]) by neon.ruby-lang.org (Postfix) with ESMTPS id AA5E3121290 for ; Sun, 13 Jan 2019 18:53:42 +0900 (JST) Received: by filter0159p3mdw1.sendgrid.net with SMTP id filter0159p3mdw1-17937-5C3B0AA3-36 2019-01-13 09:53:39.920626143 +0000 UTC m=+122346.405525299 Received: from herokuapp.com (unknown [54.198.7.14]) by ismtpd0032p1iad2.sendgrid.net (SG) with ESMTP id yuu2p0jJTtW-MyZkxcVhCg for ; Sun, 13 Jan 2019 09:53:39.912 +0000 (UTC) Date: Sun, 13 Jan 2019 09:53:40 +0000 (UTC) From: naruse@airemix.jp To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 66511 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15527 X-Redmine-Issue-Author: zverok X-Redmine-Sender: naruse 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?UqoG4vcRhHM9V1I4f4J7DhjzUfTg+8muXbMD6UD+LVRWXiib0L0C7J2dxOn6NE?= =?us-ascii?Q?5yOaxrbAcJMc8uy6QkuLOj565FTsUclizIBEC55?= =?us-ascii?Q?jZu6knwI8DjnXy9xTw+bmhn2uKeRl5xfDh968hH?= =?us-ascii?Q?pIpBi5wLOS4yC9sFXDUK=2F7qLpLpuZa8Fb8cvowC?= =?us-ascii?Q?40W5V2Cn4OwMB2VGgiQph81tL9S9sceRUnw=3D=3D?= X-ML-Name: ruby-core X-Mail-Count: 91064 Subject: [ruby-core:91064] [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 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/