Redesign of timezone object requirements
In #14850, there was timezone support introduced, there were pretty specific requirements for the Timezone object:
A timezone argument must have
local_to_utcmethod should convert a
Time-like object from the timezone to UTC, and
utc_to_localis 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
Timeobject with arbitrary offset, see discussion), recent release introduces also
#to_local, which returns
Timewith 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 for this:
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.