Bug #10677
closedRegression: Time#parse no longer automatically converts to localtime
Description
In Ruby 2.1 and before, Time#parse
automatically converted to the localtime:
Ruby 2.1:
>> require 'time'
=> true
>> ENV['TZ'] = 'Australia/Melbourne'
=> "Australia/Melbourne"
>> Time.parse("2014-12-29 20:16:32 -0400")
=> 2014-12-30 11:16:32 +1100
But in Ruby 2.2, this is not the case:
>> require 'time'
>> ENV['TZ'] = 'Australia/Melbourne'
>> Time.parse("2014-12-29 20:16:32 -0400")
=> 2014-12-29 20:16:32 -0400 # !!
>> Time.parse("2014-12-29 20:16:32 -0400").localtime
=> 2014-12-30 11:16:32 +1100
This seems to be a regression, as this is a change in default behaviour without a MAJOR
version bump, violating semver.
Updated by nobu (Nobuyoshi Nakada) almost 10 years ago
- Status changed from Open to Rejected
It's a bug fix.
Updated by parkr (Parker M) almost 10 years ago
Ok, thanks Nobuyoshi. Is this documented somewhere? It caused a lot of strife for me, and I don't think I'll be the only one. I wrote a short post about it as I had no clue this was scheduled as a bug fix. I'll update my post with a link to the original bug and the related fixes. Thanks!
Updated by akr (Akira Tanaka) almost 10 years ago
This change is intentional to preserve the original information.
Please use localtime method if you need a Time object in your local time.
Updated by parkr (Parker M) almost 10 years ago
I hear you, Akira. I am asking for a link to the issue or conversation that tracked this change. I want to know why the change was made in more detail, so I would like to read the discussion.
Updated by akr (Akira Tanaka) almost 10 years ago
There is no direct issue.
It is inspired by [Bug #9794].
Updated by binarylogic (Ben Johnson) almost 10 years ago
Akira Tanaka wrote:
There is no direct issue.
It is inspired by [Bug #9794].
Can we start a discussion? I'm surprised major changes like this are made without one. I didn't see anything in the changelogs either. This will undoubtedly cause significant problems. I've tried upgrading and came across issues with rails, multiple gems, etc.
Updated by binarylogic (Ben Johnson) almost 10 years ago
Akira Tanaka wrote:
There is no direct issue.
It is inspired by [Bug #9794].
I'd also like to add that Parker's post, and the explanation in the bottom half, is spot on ( https://byparker.com/blog/2014/ruby-2-2-0-time-parse-localtime-regression/ ).
I have a strong feeling this is going to be a major problem as people try to move forward. Adding "local" time everywhere you use Time.parse simply is not feasible. This change is also outside of the scope of a "minor" version change for ruby.
Finally, the amount of dependencies a typical ruby project has (gems). There is so much of this behavior we can not control. I can't even think of a backwards compatible patch, as gems start to adopt this new behavior, I'm not sure how we'd distinguish the "before" and "after" gems.
Updated by nobu (Nobuyoshi Nakada) almost 10 years ago
Ben Johnson wrote:
I have a strong feeling this is going to be a major problem as people try to move forward. Adding "local" time everywhere you use Time.parse simply is not feasible. This change is also outside of the scope of a "minor" version change for ruby.
I strongly disagree.
It's a bug that had ignored a part of the input which should not be ignored, and should be fixed as usual.
Updated by naruse (Yui NARUSE) almost 10 years ago
It seems a small issue that no one notice before 2.2.0 released
You may know Ruby sometimes break compatibility to achieve better specs/functions.
For Time class it didn't save its time zone before.
After 1.9 whose time objects can save its timezone, Time methods supports time zone gradually.
This change is considered as a part of them.
see also https://www.ruby-lang.org/en/news/2013/12/21/ruby-version-policy-changes-with-2-1-0/
Of course such changes may cause trouble.
Therefore we provide preview releases and release candidates to test changes.
Since Travis supports such previews, you can test your applications easily.
http://rubies.travis-ci.org/
Heroku also supports preview versions.
You can report if a change is too large.
We may withdraw the change or provide more graceful transition.
Thanks,
Updated by binarylogic (Ben Johnson) almost 10 years ago
Thank you for the explanation. I'll continue to debug and see if I can help measure it's impact. I more clearly understand the issue, and agree with the change. Unfortunately, I feel it's going to have a bigger impact than anticipated. If so, we should discuss a backwards compatible method of introducing this change.
Updated by rohandaxini (Rohan Daxini) almost 10 years ago
Ben Johnson wrote:
Thank you for the explanation. I'll continue to debug and see if I can help measure it's impact. I more clearly understand the issue, and agree with the change. Unfortunately, I feel it's going to have a bigger impact than anticipated. If so, we should discuss a backwards compatible method of introducing this change.
Something similar happened to me, but we use Time.zone.parse.
Refer the ticket here - https://bugs.ruby-lang.org/issues/10758
Updated by blmlcu (Luca B) over 9 years ago
Yui NARUSE wrote:
After 1.9 whose time objects can save its timezone,
I welcome the change, even if it's backward incompatible.
However, I noticed that although the object is meant to save its own timezone, it does not return it any more:
require 'time'
# 1.9.3 -> 2.1.5 | 2.2.0 and 2.2.1
# ---------------|-----------------
p Time.parse("2014-12-31 20:16:32 -0400").zone # "GMT" | nil
ENV['TZ'] = "Australia/Melbourne" # |
p Time.parse("2014-12-31 20:16:32 -0400").zone # "AEDT" | nil
It seems to me that to be consistent with the spirit of the change, #zone
should still return the same value.
Is this a bug? If not, what is the reason?
Updated by nobu (Nobuyoshi Nakada) over 9 years ago
You don't provide timezone, but offset only.
Try utc_offset
.