GithubHelp home page GithubHelp logo

chronic_duration's People

Contributors

bolandrm avatar brianjlandau avatar darkhelmet avatar dsiw avatar errm avatar henrypoydar avatar ianlevesque avatar jduff avatar mauriciozaffari avatar mknyazev avatar olauzon avatar pdf avatar robaman avatar shaundrong avatar spk avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

chronic_duration's Issues

NoMethodError with ChronicDuration.parse('1:1:1:1:1:1:1')

Running this:

require 'chronic_duration'

puts ChronicDuration.parse('1:1:1:1:1:1:1')

results in

NoMethodError: private method `gsub' called for nil:NilClass
cleanup at /install/path/gems/chronic_duration-0.10.6/lib/chronic_duration.rb:183
    parse at /install/path/gems/chronic_duration-0.10.6/lib/chronic_duration.rb:42
    <top> at chronic_test.rb:3

"0 hours"?

I see from the code that both parse() and output() explicitly return nil if the input/output ends up being 0... out of curiosity, is there a particular reason for this behavior? In other words, is there some reason that it shouldn't just return 0 for the input "0 hours"?

I thought I should check before diving into a fork and adding some configuration options. :-)

Date Ranges

I am writing my own solution to calculate date ranges (e.g. May 22 2014 to June 3 2015) based on chronic. I would gladly contribute this solution if needed.

Use OmNomNum

Hey all!

I just created the library OmNomNum, a C extension that I aim to use as a replacement for Numerizer, which this library uses. OmNomNum currently does not support fractions, so it's not a 100% replacement for Numerizer just yet.

The main purpose of adding this issue was to let you know that my library exists. Ideally other Rubyists using this library could benefit from OmNomNum. Let me know if you're interested in possibly working together to add support for OmNomNum to this library.

If you have any questions, just let me know.

👍

Internationalization

This is more of an enhancement than a direct issue. I would like to see support for localizations and internationalization. I hereby volunteer as a contributor for the Icelandic version of the system! :)

parse(keep_zero: true) treats empty strings like 0

[50] pry(main)> ChronicDuration.parse("   ")
=> nil
[51] pry(main)> ChronicDuration.parse("   ", keep_zero: true)
=> 0

I believe that empty strings should still be treated as invalid and return nil. There is a difference between not entering anything and explicitly entering 0.

Case matching

The class is very specific about case.

20 mins parses perfectly, but '20 Mins' causes problems.

Worth switching on case insensitive matching?

#output returns negative numbers

For example,
186918431
returns
6 yrs -27 days 9 hrs 47 mins 11 secs

I believe this can be fixed if the result is calculated from most significant digit (year) to least, rather than, t'other way around.

already initialized constant

How do I get rid of this?

C:/Ruby192/lib/ruby/gems/1.9.1/bundler/gems/chronic_duration-6c1c5cb7ffb2/lib/numerizer.rb:5: warning: already initialized constant DIRECT_NUMS
C:/Ruby192/lib/ruby/gems/1.9.1/bundler/gems/chronic_duration-6c1c5cb7ffb2/lib/numerizer.rb:30: warning: already initialized constant TEN_PREFIXES
C:/Ruby192/lib/ruby/gems/1.9.1/bundler/gems/chronic_duration-6c1c5cb7ffb2/lib/numerizer.rb:41: warning: already initialized constant BIG_PREFIXES

'12 months' => 360 days

It might be preferable if numerous months were longer than 30 days on average. What do you think?

not showing years for large month count

Expecting: 50 years 10 months 11 days (18,578 days)

Actual: 619 mos 8 days (18,578 days)

The calculation for years seems to be off.

irb> require 'date'
=> true
irb> require 'chronic_duration'
=> true

irb> b = Date.new( 1963, 11, 27 )
=> #<Date: 1963-11-27 ((2438361j,0s,0n),+0s,2299161j)>

irb> puts "birthdate : #{b.strftime('%a, %d %b %Y')}"
birthdate : Wed, 27 Nov 1963
=> nil

irb> bj = b.jd
=> 2438361

irb> n = Date.today
=> #<Date: 2014-10-08 ((2456939j,0s,0n),+0s,2299161j)>

irb> puts "now       : #{n.strftime('%a, %d %b %Y')}"
now       : Wed, 08 Oct 2014
=> nil

irb> nj = n.jd
=> 2456939

irb> d = n - b
=> (18578/1)

irb> dj = nj - bj
=> 18578

irb> puts "age       : " << ChronicDuration.output( ( ( dj * 24 * 60 * 60 )) ) << " (#{dj} days)"
age       : 619 mos 8 days (18,578 days)
=> nil

New version of chronic_duration gem

Hi, would it be possible to release a new version of the gem? v0.10.2 has the following problem:

ChronicDuration.output(ChronicDuration.parse('6 years 2 days 1 hour'))
=> "6 yrs 1 mo -28 days 1 hr"

This issue was previously raised in #16 and seems to have been fixed by #17.

We use chronic_duration in https://github.com/flpjck/flapjack/ and as that ships a gem, we can't point to a specific branch or commit in the gemspec, we're stuck with the versions released to rubygems.org.

Failing to round at the year mark?

require "chronic_duration"

360.upto(370) do |d|
    time = Time.now
    t = time - (d * 60 * 60 * 24) + rand * 50
    puts "%s: %s | %s" % [ t,
                           time - t,
                           ChronicDuration.output(time - t, units: 1)]
end

Output:

2018-04-29 15:54:35 +0100: 31103965.53874908 | 11 mos
2018-04-28 15:54:19 +0100: 31190381.52392838 | 12 mos
2018-04-27 15:54:07 +0100: 31276793.729049 | 12 mos
2018-04-26 15:54:29 +0100: 31363172.040289067 | 12 mos
2018-04-25 15:54:30 +0100: 31449570.683521885 | 12 mos
2018-04-24 15:54:19 +0100: 31535982.140896846 | 12 mos
2018-04-23 15:54:49 +0100: 31622352.089178756 | 1.0020518698880383 yrs
2018-04-22 15:54:45 +0100: 31708755.525656532 | 1.00478982957058 yrs
2018-04-21 15:54:06 +0100: 31795195.078492984 | 1.0075289337114668 yrs
2018-04-20 15:54:04 +0100: 31881596.925340295 | 1.0102668430216586 yrs
2018-04-19 15:54:18 +0100: 31967982.62229197 | 1.0130042405725395 yrs

The workaround appears to be to truncate time - t to an integer, and pass that instead.

ChronicDuration::parse("0min") returns nil, not 0

ChronicDuration::parse("0") returns nil, not 0.
ChronicDuration::parse("0s") returns nil, not 0.
ChronicDuration::parse("0min") returns nil, not 0.

This is unexpected behavior, since those are valid strings that represent a time duration of zero.

messages warning

I'm using ruby 1.9.2 rails 3.0.6 and the 0.9.4 gem but still the messages appear:
warning: Already initialized constant DIRECT_NUMS
warning: Already initialized constant TEN_PREFIXES
warning: Already initialized constant BIG_PREFIXES

problem after last saturday (daylight saving changed)

Hello,

I am in the Timezone GMT+1 and last saturday occured the change from summertime to wintertime. After that one of my tests stopped working. The test looks like this:

context 'format for 10 days 23 hours 15 minutes 30 seconds' do
  let(:tnow) { Time.now }
  let(:tdiff) { tnow - (tnow - 10.days - 23.hours - 15.minutes - 30.seconds ) }
  it 'returns the correct format' do
    expect(ChronicDuration.output(tdiff, :format => :short)).to eq('10d 23h 15m 30s')
  end
end

The error is

expected: "10d 23h 15m 30s"
got: "11d 15m 30s"

So I suppose this is a problem with the daylight saving. Is there a possibility to circumvent this error?

Thanks in advance

Rudolf Fäder

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.