Feature #14850

Add official API for setting timezone on Time

Added by sam.saffron (Sam Saffron) 3 months ago. Updated 20 days ago.

Target version:


Only way of setting zone on a Time object appears to be via marshalling and messing with ENV.

>> ENV['TZ'] = 'America/New_York'
=> "EDT"
>> ENV['TZ'] = 'Europe/London'
=> "BST"

Is there any particular reason there is no direct, supported API for setting timezone?

ActiveSupport carries 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) 3 months 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:'2007-02-10 15:30:45')

I am not sure this should exist in core ruby. People will
be confused as to Time.parse() versus
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.

#2 [ruby-core:88809] Updated by nobu (Nobuyoshi Nakada) 20 days ago

Here is a patch to extend and Time#getlocal for timezone support.
A timezone object should have local_to_utc, utc_to_local and utc_offset methods, like timezone gem.

Also available in: Atom PDF