{"action":"created","issue":{"url":"https://api.github.com/repos/jruby/jruby/issues/1795","repository_url":"https://api.github.com/repos/jruby/jruby","labels_url":"https://api.github.com/repos/jruby/jruby/issues/1795/labels{/name}","comments_url":"https://api.github.com/repos/jruby/jruby/issues/1795/comments","events_url":"https://api.github.com/repos/jruby/jruby/issues/1795/events","html_url":"https://github.com/jruby/jruby/issues/1795","id":37215805,"number":1795,"title":"Time#zone using Time#local","user":{"login":"robin850","id":354185,"avatar_url":"https://avatars.githubusercontent.com/u/354185?v=3","gravatar_id":"","url":"https://api.github.com/users/robin850","html_url":"https://github.com/robin850","followers_url":"https://api.github.com/users/robin850/followers","following_url":"https://api.github.com/users/robin850/following{/other_user}","gists_url":"https://api.github.com/users/robin850/gists{/gist_id}","starred_url":"https://api.github.com/users/robin850/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/robin850/subscriptions","organizations_url":"https://api.github.com/users/robin850/orgs","repos_url":"https://api.github.com/users/robin850/repos","events_url":"https://api.github.com/users/robin850/events{/privacy}","received_events_url":"https://api.github.com/users/robin850/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/jruby/jruby/labels/core","name":"core","color":"02e10c"},{"url":"https://api.github.com/repos/jruby/jruby/labels/JRuby%201.7.x","name":"JRuby 1.7.x","color":"eb6420"},{"url":"https://api.github.com/repos/jruby/jruby/labels/JRuby%209000","name":"JRuby 9000","color":"bfe5bf"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2014-07-06T10:29:58Z","updated_at":"2016-02-13T19:44:31Z","closed_at":null,"body":"Hello,\r\n\r\nWe've discovered an inconsistency of JRuby with MRI when dealing with time zones. The behavior is kind of weird on MRI anyway but we wanted with @febuiles to bring a discussion around this. `Time.local` supports ten parameters for historical reasons (when dealing with `#to_a` for instance) but the passed time zone is ignored and MRI and Rubinius returns the current time zone:\r\n\r\n~~~ruby\r\n>> time = Time.local(0, 30, 1, 30, 10, 2005, 0, 0, false, 'US/Eastern');\r\n\r\n>> RUBY_ENGINE\r\n=> \"ruby\"\r\n>> time.zone\r\n=> \"CEST\" # In my case\r\n\r\n>> RUBY_ENGINE\r\n=> \"rbx\"\r\n>> time.zone\r\n=> \"CEST\"\r\n~~~\r\n\r\nHowever, JRuby has a sightly different behavior that isn't the same between JRuby 1.7.12 and 1.7.13:\r\n\r\n~~~ruby\r\n>> JRUBY_VERSION\r\n=> \"1.7.12\"\r\n>> time.zone\r\n=> nil\r\n\r\n>> JRUBY_VERSION\r\n=> \"1.7.13\"\r\n>> time.zone\r\n=> \"EDT\"\r\n~~~\r\n\r\nThe returned time zone is wrong anyway because EDT stands for \"Eastern Daylight Time\" while `false` has been passed as the ninth parameter (i.e. isdst).\r\n\r\nTo bring JRuby in line with MRI and Rubinius, [these lines](https://github.com/jruby/jruby/blob/60442ef0cdc7fadf7ede5dba93507c9a12f295a3/core/src/main/java/org/jruby/RubyTime.java#L1200-L1209) should not be reached when we are calling `Time#local`.\r\n\r\nHave a nice day!"},"comment":{"url":"https://api.github.com/repos/jruby/jruby/issues/comments/183736341","html_url":"https://github.com/jruby/jruby/issues/1795#issuecomment-183736341","issue_url":"https://api.github.com/repos/jruby/jruby/issues/1795","id":183736341,"user":{"login":"headius","id":10135,"avatar_url":"https://avatars.githubusercontent.com/u/10135?v=3","gravatar_id":"","url":"https://api.github.com/users/headius","html_url":"https://github.com/headius","followers_url":"https://api.github.com/users/headius/followers","following_url":"https://api.github.com/users/headius/following{/other_user}","gists_url":"https://api.github.com/users/headius/gists{/gist_id}","starred_url":"https://api.github.com/users/headius/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/headius/subscriptions","organizations_url":"https://api.github.com/users/headius/orgs","repos_url":"https://api.github.com/users/headius/repos","events_url":"https://api.github.com/users/headius/events{/privacy}","received_events_url":"https://api.github.com/users/headius/received_events","type":"User","site_admin":false},"created_at":"2016-02-13T19:44:30Z","updated_at":"2016-02-13T19:44:30Z","body":"Ok, I think I have a lead.\r\n\r\nI think the problem here is that the given time and date are right at the DT/ST boundary for 2005 in that time zone.\r\n\r\nIn 2005, DST transition occured on October 30 at 2AM. You gave a time of 1:30AM, which for this case would require us to negotiated which side of the DST boundary we are on. I believe it's picking EDT because it sees the time is before 2AM, and therefore pre-transition.\r\n\r\nWe build up the time starting with all zeros and UTC and add in the month, day, hour, minute, etc, and then eventually apply the time zone. There's some logic related to the isDST parameter that appears to try to negotiate which side of the DT/ST boundary we are on, but passing true does not seem to affect anything. 1:30AM always comes out as EDT, and 2:30AM always comes out as EST.\r\n\r\nI modified our code to use the isdst the same way MRI does, flopping the pre/post-transition flag, and I was able to get it to do EST and EDT predictably. Of course this isn't correct, since MRI just ignores the given time zone entirely.\r\n\r\nAnd removing our time zone argument handling broke a bunch of other things."}}