Add official API for setting timezone on Time
Only way of setting zone on a Time object appears to be via marshalling and messing with ENV.
>> ENV['TZ'] = 'America/New_York' >> Time.now.zone => "EDT" >> ENV['TZ'] = 'Europe/London' >> Time.now.zone => "BST"
Is there any particular reason there is no direct, supported API for setting timezone?
ActiveSupport carries http://api.rubyonrails.org/v5.1/classes/ActiveSupport/TimeWithZone.html for this exact reason, it would be nice for core Ruby to support this out-of-the-box
#1 [ruby-core:87508] Updated by shevegen (Robert A. Heiler) 29 days ago
I agree in regards to it being odd that in an OOP-centric language
we have to fiddle with environment variables.
Irrelevant fun fact:
I once set TZ as "alias" (well, export TC= some value) towards '.tar.gz'
or something like that in the bash shell. Turns out that was not good
for when you want to compile programs from source in bash ... things
failed to compile/work past that point. :)
There are quite a few environment variables that can induce an
odd behaviour. This is not so much related to your issue request
but I can completely understand where you are coming from,
because while manipulating ENV works (I use it to modify CFLAGS
for example, in the ruby-project that I use to compile programs
from source), it's not extremely elegant.
So personally, I agree with your general issue request about
having some way to set the timezone. I don't care so much
where it resides (Time, Date... whatever, though the fewer
cases where time-related information is stored, the better).
API-wise, though, I think the ActiveSupport API or choice of
name is bad.
I am not sure about:
But I think that this is mostly a detail that can be expanded
on when matz/the ruby core team would approve of this.
Some of the API in ActiveSupport is weird to me though.
This one for example:
I am not sure this should exist in core ruby. People will
be confused as to Time.parse() versus Time.zone.parse()
so I don't think this is great ...
There is one thing for you to consider in the request, because
what happens in regards to backwards compatibility? Some people
may rely on that ENV behaviour. So the method should also clearly
state whether it will modify ENV, or have no effect on ENV (but
in that case, what happens when people modify ENV['TZ'] - will
that have an impact?)
I think these details have to be added into the issue request.
Perhaps as a compromise an argument could be used to denote
this, with the default argument retaining the old behaviour
as-is, whereas people who want an API + method need to pass
some additional argument to it.