Project

General

Profile

Actions

Bug #10677

closed

Regression: Time#parse no longer automatically converts to localtime

Added by parkr (Parker M) almost 10 years ago. Updated over 9 years ago.

Status:
Rejected
Assignee:
Target version:
ruby -v:
ruby 2.2.0p0 (2014-12-25 revision 49005) [x86_64-darwin14]
[ruby-core:67215]

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?

Actions #13

Updated by nobu (Nobuyoshi Nakada) over 9 years ago

You don't provide timezone, but offset only.
Try utc_offset.

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0