Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

strptime incorrectly parses the date #132

Closed
dmitry opened this issue Jan 6, 2015 · 12 comments
Closed

strptime incorrectly parses the date #132

dmitry opened this issue Jan 6, 2015 · 12 comments

Comments

@dmitry
Copy link

dmitry commented Jan 6, 2015

I have following situation:

Date.strptime("11-01-08", '%Y-%m-%d')
# Thu, 08 Jan 0011
require 'timecop'
# true
Date.strptime("11-01-08", '%Y-%m-%d')
# Sat, 10 Jan 0011

Even Date::ITALY works as it should:

Date.strptime("11-01-08", '%Y-%m-%d', Date::ITALY)
# Thu, 08 Jan 0011
@yaauie
Copy link
Contributor

yaauie commented Jan 6, 2015

Very odd, I'm getting odd but different results here:

Date.strptime("11-01-08", '%Y-%m-%d').strftime
# => "0011-01-08"
require 'timecop'
# => true
Date.strptime("11-01-08", '%Y-%m-%d').strftime
# => "0011-01-10"
Date.strptime("11-01-08", '%Y-%m-%d', Date::ITALY).strftime
# => "0011-01-10"

I would wager that it's because Ruby Time objects are backed by a float representing the offset from 1970-01-01T00:00:00Z, and that the year 0011 is far enough away that there is a loss of precision.

@dmitry
Copy link
Author

dmitry commented Jan 6, 2015

Any ideas how to fix that issue(s)?

PS. I have ruby 1.9.3

@dmitry
Copy link
Author

dmitry commented Jan 6, 2015

Looks like another issue reported is here: #116

@sos4nt
Copy link

sos4nt commented Nov 14, 2016

It happens because Timecop uses Time#to_date in lib/timecop/time_extensions.rb#L62.

Time#to_date treats the input as proleptic Gregorian calendar date values, i.e.:

Time.strptime("11-01-08", '%Y-%m-%d').to_date
#=> #<Date: 0011-01-10 ((1725085j,0s,0n),+0s,2299161j)>

is equivalent to: (the unpatched)

Date.strptime("11-01-08", '%Y-%m-%d', Date::GREGORIAN).new_start
#=> #<Date: 0011-01-10 ((1725085j,0s,0n),+0s,2299161j)>

@daveallie
Copy link

Any update on whether this issue will be resolved?

Annoyingly, including timecop in a test suite means that tests can pass, even though the dates being parsed could be out by a few days. @sos4nt's answer here states that attempting to parse and dates before 04/10/1582 will lead to discrepencies.

@lisbethmarianne
Copy link

We see this:

irb(main):001:0> week = '201810'
=> "201810"
irb(main):002:0> Date.strptime(week, "%Y%W")
=> Mon, 05 Mar 2018
irb(main):003:0> require 'timecop'
=> true
irb(main):004:0> Date.strptime(week, "%Y%W")
=> Mon, 01 Jan 2018

@dmitry
Copy link
Author

dmitry commented Oct 27, 2018

Solution is here: #217

@kwerle
Copy link
Contributor

kwerle commented Jun 11, 2019

    it "should accept dates prior to 1900s with century information (e.g. 6/1/0007)" do
      expect(ActiveRecord::Type::Date.new.type_cast_from_user("6/1/0007")).to eq(Date.new(7, 6, 1))
    end

with Timecop:

  1) ActiveRecord::Type::Date#type_cast_from_user(value)·default locale·should accept dates prior to 1900s with century information (e.g. 6/1/0007)
    Failure/Error: expect(ActiveRecord::Type::Date.new.type_cast_from_user("6/1/0007")).to eq(Date.new(7, 6, 1))

      expected: Wed, 01 Jun 0007
           got: Fri, 03 Jun 0007

@dmitry
Copy link
Author

dmitry commented Jun 14, 2019

@kwerle please check the pull request #217, probably this one should work in your case.

@kwerle
Copy link
Contributor

kwerle commented Jun 15, 2019

Submitted a new pr: #242. Fixed tests (mostly Gemfile updates).

@spalenza
Copy link

I changed to use DateTime with to_date instead of Date.

 DateTime.strptime("11-01-08", '%Y-%m-%d').to_date
 => Thu, 08 Jan 0011

@joshuacronemeyer
Copy link
Collaborator

I'm closing this issue because the original behavior mentioned has changed. It doesn't seem to be a bug anymore. I have created a new issue for the behavior that @lisbethmarianne mentioned in her comment tho. It can be found here #380

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants