From: Joseph Jones Date: 2015-12-17T21:06:48-07:00 Subject: [ruby-core:72284] [Ruby trunk - Bug #11595] Time#utc? and Time#gmt? return misleading results based on $TZ --56738658_7644a45c_16c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Joseph Jones liked your message with Boxer. On November 30, 2015 at 06:24= :39 MST, yasuhiro6194=40gmail.com wrote:Issue =2311595 has been updated b= y Yasuhiro Nakamura.Assignee set to Akira Tanaka-------------------------= ---------------Bug =2311595: Time=23utc=3F and Time=23gmt=3F return misle= ading results based on =24TZhttps://bugs.ruby-lang.org/issues/11595=23cha= nge-55165* Author: David Celis* Status: Open* Priority: Normal* Assignee:= Akira Tanaka* ruby -v: ruby 2.2.3p173 (2015-08-18 revision 51636) =5Bx86= =5F64-darwin14=5D* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN--= --------------------------------------There is an issue with Time=23utc=3F= and its alias, Time=23gmt=3F, that return misleading results based on th= e value of the TZ environment variable. It seems that the only way for a = Time instance to return =60true=60 for =60utc=3F=60 is if you explicitly = call =60=23utc=60 on it before:=7E=7E=7EENV=5B'TZ'=5D =3D 'UTC'=23 =3D> =22= UTC=22time =3D Time.now=23 =3D> 2015-10-14 19:30:00 +0000time.utc=3F=23 =3D= > falsetime =3D time.utc=23 =3D> 2015-10-14 19:30:00 UTCtime.utc=3F=23 =3D= > true=7E=7E=7EThis seems misleading based on the value of =24TZ being =22= UTC=22. The expected result for calling =60Time.now.utc=3F=60 in this cas= e would be =60true=60, as would that be expected for time zones that are = considered links to =22UTC=22 based on the =5Btzdata list=5D(https://en.w= ikipedia.org/wiki/List=5Fof=5Ftz=5Fdatabase=5Ftime=5Fzones). These includ= e =22UTC=22, =22GMT=22, =22Etc/UTC=22, =22Etc/GMT=22, =22Universal=22, et= c.-- https://bugs.ruby-lang.org/ --56738658_7644a45c_16c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Joseph Jones liked your message with Boxer.


= On November 30, 2015 at 06:24:39 MST, yasuhiro6194=40gmail.com wrote:
Issue =2311595 has been u= pdated by Yasuhiro Nakamura.

Assignee set to Akira Tanaka

----------------------------------------
Bug =2311595: Time=23= utc=3F and Time=23gmt=3F return misleading results based on =24TZ
ht= tps://bugs.ruby-lang.org/issues/11595=23change-55165

* Author:= David Celis
* Status: Open
* Priority: Normal
* Assignee:= Akira Tanaka
* ruby -v: ruby 2.2.3p173 (2015-08-18 revision 51636) = =5Bx86=5F64-darwin14=5D
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.= 2: UNKNOWN
----------------------------------------
There is an= issue with Time=23utc=3F and its alias, Time=23gmt=3F, that return misle= ading results based on the value of the TZ environment variable. It seems= that the only way for a Time instance to return =60true=60 for =60utc=3F= =60 is if you explicitly call =60=23utc=60 on it before:

=7E=7E= =7E
ENV=5B'TZ'=5D =3D 'UTC'
=23 =3D> =22UTC=22
time =3D Ti= me.now
=23 =3D> 2015-10-14 19:30:00 +0000
time.utc=3F
=23 = =3D> false
time =3D time.utc
=23 =3D> 2015-10-14 19:30:00 UTCtime.utc=3F
=23 =3D> true
=7E=7E=7E

This seems m= isleading based on the value of =24TZ being =22UTC=22. The expected resul= t for calling =60Time.now.utc=3F=60 in this case would be =60true=60, as = would that be expected for time zones that are considered links to =22UTC= =22 based on the =5Btzdata list=5D(https://en.wikipedia.org/wiki/List=5Fo= f=5Ftz=5Fdatabase=5Ftime=5Fzones). These include =22UTC=22, =22GMT=22, =22= Etc/UTC=22, =22Etc/GMT=22, =22Universal=22, etc.



-= -
https://bugs.ruby-lang.org/
= --56738658_7644a45c_16c--