From: zverok.offline@gmail.com
To: ruby-core@ruby-lang.org
Subject: [ruby-core:91034] [Ruby trunk Feature#15527] Redesign of timezone object requirements
Date: Sat, 12 Jan 2019 09:02:23 +0000 (UTC) [thread overview]
Message-ID: <redmine.issue-15527.20190112090221.fb0d4bfd67694cde@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-15527.20190112090221@ruby-lang.org
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')
# => #<TZInfo::DataTimezone: 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/
next parent reply other threads:[~2019-01-12 9:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <redmine.issue-15527.20190112090221@ruby-lang.org>
2019-01-12 9:02 ` zverok.offline [this message]
2019-01-13 9:53 ` [ruby-core:91064] [Ruby trunk Feature#15527] Redesign of timezone object requirements naruse
2019-01-14 18:40 ` [ruby-core:91086] " zverok.offline
2019-02-01 9:41 ` [ruby-core:91373] " nobu
2019-02-01 18:06 ` [ruby-core:91378] " zverok.offline
2019-02-02 11:15 ` [ruby-core:91386] " nobu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.ruby-lang.org/en/community/mailing-lists/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=redmine.issue-15527.20190112090221.fb0d4bfd67694cde@ruby-lang.org \
--to=ruby-core@ruby-lang.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).