mojombo / chronic Goto Github PK
View Code? Open in Web Editor NEWChronic is a pure Ruby natural language date parser.
Home Page: http://injekt.github.com/chronic
License: MIT License
Chronic is a pure Ruby natural language date parser.
Home Page: http://injekt.github.com/chronic
License: MIT License
This is just a syntax thing, not a huge problem at all... The complex examples don't seem to support strings like "first", "second", "third". The following statement works:
ruby-1.9.2-p0 > Chronic.parse('3rd tuesday this december')
=> 2010-12-21 12:00:00 -0600
While the following statement throws a TypeError:
ruby-1.9.2-p0 > Chronic.parse('third tuesday this december')
TypeError: can't iterate from Time
I love Chronic. It's wonderful. But it looks like this version 3.0 with time zone support was never pushed to Rubyforge -- which means it never made it to Gemcutter. The standard 'gem install chronic' is now years out of date and doesn't have the time zone features built in. I hope you won't mind taking a minute or two to update it on the new canonical gem source.
Chronic.parse('8/15') #=> Sun Aug 16 12:00:00 -0400 2015
Trying a couple of other months these all work fine:
ruby-1.9.2-p0 > Chronic.parse('3rd thursday this October')
=> 2010-10-21 12:00:00 +0100
ruby-1.9.2-p0 > Chronic.parse('3rd thursday this December')
=> 2010-12-16 12:00:00 +0000
However November is a day out, it should be the 18th:
ruby-1.9.2-p0 > Chronic.parse('3rd thursday this November')
=> 2010-11-19 11:00:00 +0000
I get the same error in ruby 1.9.2p0 and 1.8.7p174. The only weird datey thing in the near future is a switch back from DST (GMT +1) to GMT in the next few days. December however works fine:
ruby-1.9.2-p0 > Chronic.parse('3rd thursday in December')
=> 2010-12-16 12:00:00 +0000
Unlike 0.2.3, 0.3.0 cannot handle parsing the current month name in the past context.
Throws RuntimeError with baffling message.
irb> Chronic.parse(Time.now.strftime('%b'), :context => :past)
RuntimeError: Current month should be set by now
Chronic needs to be able to handle any correct month string thrown at it, exceptions should not be thrown because we happen to ask it to return the same month a year ago.
Chronic.parse("1234") should result in tomorrow at 12:34 PM (assuming it's after 12:34PM local time), but results in tomorrow at 12:34 AM:
irb(main):003:0> Chronic.parse("1234")
=> Wed Oct 14 00:34:00 -0700 2009
:context is ignored when time is specified with day of week
Chronic.parse("Sun", :context => :past)
=> Sun Jul 26 12:00:00 -0700 2009
------ expectedChronic.parse("Sun at 2:18pm")
=> Sun Aug 02 14:18:00 -0700 2009
------ expectedChronic.parse("Sun at 2:18pm", :context => :past)
=> Sun Aug 02 14:18:00 -0700 2009
----- expecting Sun Jul 26 14:18:00 -0700 2009
Here is the current time: 2010-05-08 23:12:06 -0400
Here is the output, right now, when trying to parse 'today':
ruby-1.9.1-p378 > Chronic.parse('today', :now => Time.now)
=> 2010-05-09 00:00:00 -0400
Interestingly enough, here is the output when parsing 'yesterday'
ruby-1.9.1-p378 > Chronic.parse('yesterday', :now => Time.now)
=> 2010-05-07 12:00:00 -0400
So basically after 11pm EST today no longer exists :)
I'd love a way to access the specificity of the search for filtering processes. e.g. "3 months ago" would return something like:
{
second: false,
minute: false,
hour: false,
day: false,
week: false,
month: true,
quarter: false,
season: false,
year: false
}
A request like: "8 months ago yesterday at 5pm" would return:
{
second: false,
minute: false,
hour: true,
day: true,
week: false,
month: true,
quarter: false,
season: false,
year: false
}
Our app's test suite failed today due to a bug in chronic related to daylight savings ending. I've reproduced the bug in the chronic test suite here:
https://github.com/weplay/chronic/tree/daylight_savings_end_bug
The behavior is that parsing "11:34 PM' on daylight savings' end date gives you 11:34 AM back, and parsing "11:34 AM" gives you nil back.
I don't have a fix yet, but I thought the test case might be useful to others.
If you're feeling studly, you could include a setting for "start of quarter-year", e.g., Oct 1st. Otherwise, the quarter-year would start on Jan 1, 00:00, and .. I think .. be almost exactly equivalent to seasons.
Hi there,
Are there any plans to support i18n of Chronic? Maybe exporting the strings and then evaluate them later as regexes?
Any toughts on that?
Tested on Ubuntu 10.10+ -- see also this discussion. Seems to fail across Ruby versions
:; git clone git://github.com/mojombo/chronic.git
Cloning into chronic...
remote: Counting objects: 2059, done.
remote: Compressing objects: 100% (955/955), done.
remote: Total 2059 (delta 1344), reused 1784 (delta 1085)
Receiving objects: 100% (2059/2059), 277.02 KiB | 338 KiB/s, done.
Resolving deltas: 100% (1344/1344), done.
:; cd chronic/
:; rake test (in /home/solidsnack/sandbox/chronic/tmp/chronic)
/usr/bin/ruby1.8 -I"lib:lib:test" "/var/lib/gems/1.8/gems/rake-0.8.7/lib/rake/rake_test_loader.rb" "test/test_RepeaterWeekend.rb" "test/test_RepeaterHour.rb" "test/test_Span.rb" "test/test_MiniDate.rb" "test/test_parsing.rb" "test/test_RepeaterMinute.rb" "test/test_RepeaterYear.rb" "test/test_Handler.rb" "test/test_RepeaterMonth.rb" "test/test_RepeaterTime.rb" "test/test_RepeaterFortnight.rb" "test/test_RepeaterWeek.rb" "test/test_RepeaterDayName.rb" "test/test_RepeaterWeekday.rb" "test/test_Numerizer.rb" "test/test_RepeaterSeason.rb" "test/test_Token.rb" "test/test_DaylightSavings.rb" "test/test_RepeaterMonthName.rb" "test/test_Chronic.rb" Loaded suite /var/lib/gems/1.8/gems/rake-0.8.7/lib/rake/rake_test_loader Started
............................................................F............................................................. Finished in 0.434959 seconds.
1) Failure:
test_parse_guess_gr(TestParsing) [./test/test_parsing.rb:409]:
<Tue Oct 24 12:30:00 +0000 2006> expected but was
<Tue Oct 24 12:00:00 +0000 2006>.
122 tests, 506 assertions, 1 failures, 0 errors
rake aborted!
Command failed with status (1): [/usr/bin/ruby1.8 -I"lib:lib:test" "/var/li...]
Chronic.pre_normalize removed all dots from the numerized string, which looks quite like a bug to me:
>> Numerizer.numerize 'two and a half years'
=> "2.5 years"
>> Chronic.pre_normalize 'two and a half years'
=> "25 years"
I am using version v0.2.3
I am having issues when a date is specified as '5/5/2011' that chronic assumes that the format is 'mm/dd/yy' where sometimes this is not the case, I really need to specify this on a user by user basis (users from around the world).
Is it possible to have some sort of setting for Chronic that says to use dd/mm or mm/dd when parsing? I would then be able to set this in my application controller based on the logged in user.
If there is already a workaround for this, please let me know.
One might expect Chronic.parse('30 February 2011') to yield nil... as there never a 30'th of February... yet it yields 02 March 2011.
30 days hath September, April, June and November
Same-ish goes for the "31st" of those 4 months too yielding the 1st of the following month.
Same-ish goes for Chronic.parse('31 February 2011') yielding 03 March 2011... and the 29th of February yielding the 1st of March on non-leap years.
If it is March, one month ago should probably be February. If it is after the 28th of march (or 29th on leap year), finding a date for "1 month ago" will find March first.
It seems like this is done on purpose in Time+construct+, not sure why.
Chronic::RepeaterMonth.new(:month).offset_by(Time.mktime(2010, 3, 29), 1, :past).month == 2
I might be missing something obvious, but I think it's really strange that "7/12/11" parses to 2007-12-11 while "7/13/11" parses to 2011-07-13.
ruby-1.9.2-p290 :011 > Chronic.parse("7/12/11")
+---------------------------------------------------
| [7(repeater-time-25200?, scalar, scalar-day-7, scalar-month-7, scalar-year-2007) , /(separator-slashordash-slash) , 12(repeater-time-0?, scalar, scalar-day-12, scalar-month-12, scalar-year-2012) , /(separator-slashordash-slash) , 11(repeater-time-39600?, scalar, scalar-day-11, scalar-month-11, scalar-year-2011) ]
+---------------------------------------------------
-date
Handler: handle_sy_sm_sd
=> 2007-12-11 12:00:00 -0500
ruby-1.9.2-p290 :012 > Chronic.parse("7/13/11")
+---------------------------------------------------
| [7(repeater-time-25200?, scalar, scalar-day-7, scalar-month-7, scalar-year-2007) , /(separator-slashordash-slash) , 13(repeater-time-46800?, scalar, scalar-day-13, scalar-year-2013) , /(separator-slashordash-slash) , 11(repeater-time-39600?, scalar, scalar-day-11, scalar-month-11, scalar-year-2011) ]
+---------------------------------------------------
-date
Handler: handle_sm_sd_sy
=> 2011-07-13 12:00:00 -0400
Because 12 could be a month, Chronic matches handle_sy_sm_sd
instead of handle_sm_sd_sy
, which is what the second date matches. I would expect that it would always match the second, unless the first part of the date is four digits (i.e. 2007/12/11), so this seems like a bug to me.
I've got Chronic installed on my Dreamhost server, I'm not sure which version it was running, but it seems to have been updated to Chronic 0.6.2 recently.
Anyway, it's now failing on date strings it was previously passing on. For example
created_at = Chronic.parse("12 May 2010 2:04:34 PM Eastern Daylight Time")
=> nil
I'm not sure if anything else has broken on the server, but this certainly is causing a stink for me now (tried it with 'ET' instead of "Eastern Daylight Time", too and it gives the same result)
My ruby version is 1.8.7, and I'm using Chronic in a Sinatra app.
It would be nice if you could extract all the regex into a language file, because then we could extend it for other languages.
I would then volunteer for german language support.
I just forked this repo and started the tests and got the following failing tests:
1) Failure:
test_days_in_november(TestParsing) [./test/test_parsing.rb:699]:
<Sun Nov 04 11:00:00 +0100 2007> expected but was
<Sun Nov 04 12:00:00 +0100 2007>.
2) Failure:
test_parse_guess_o_r_g_r(TestParsing) [./test/test_parsing.rb:583]:
<Fri Mar 16 12:30:00 +0100 2007> expected but was
<Fri Mar 16 11:30:00 +0100 2007>.
3) Failure:
test_seasons(TestParsing) [./test/test_parsing.rb:662]:
<Tue Mar 20 00:00:00 +0100 2007> expected but was
<Tue Mar 20 23:00:00 +0100 2007>.
I'm working in the time GMT +1 (western europe) could this be the problem?
if you pass the day with format xxth, like 7th, then the year return will always be 2011.
ruby-1.8.7-p302 > Chronic.parse("November 7th 2000")
=> Mon Nov 07 20:00:00 +0800 2011
ruby-1.8.7-p302 > Chronic.parse("November 7 2000")
=> Tue Nov 07 12:00:00 +0800 2000
Very very weird bug. Today, our system starting to hang when trying to parse one of the following strings:
spring
summer
autumn
winter
It didn't happen a few days ago. It looks like an infinite loop.
See test here. This test passes on Ruby 1.8.7 and fails on 1.9+
>> RUBY_VERSION
=> "1.8.7"
>> Time.local(79, 12)
=> Sat Dec 01 00:00:00 +0000 1979
>> RUBY_VERSION
=> "1.9.2"
>> Time.local(79, 12)
=> 0079-12-01 00:00:00 +0100
Ruby 1.8.7 assumes 1979, Ruby 1.9.2 assumes 0079
May not be worth looking into until Ruby 1.9.2 is actually released, but on 1.9.2-head Chronic is having some issues. Main ones I caught:
Chronic.parse("5/24/10") gives my 0010-05-24 instead of 2010-05-24
Chronic.parse("2010-05-24 09:00:00") throws an error now:
TypeError: can't convert Chronic::RepeaterTime::Tick into an exact number from /Users/dylan/.rvm/gems/ruby-1.9.2-head/gems/chronic-0.2.3/lib/chronic/repeaters/repeater_time.rb:74:in `+' from /Users/dylan/.rvm/gems/ruby-1.9.2-head/gems/chronic-0.2.3/lib/chronic/repeaters/repeater_time.rb:74:in `block in next' from /Users/dylan/.rvm/gems/ruby-1.9.2-head/gems/chronic-0.2.3/lib/chronic/repeaters/repeater_time.rb:67:in `catch' from /Users/dylan/.rvm/gems/ruby-1.9.2-head/gems/chronic-0.2.3/lib/chronic/repeaters/repeater_time.rb:67:in `next' from /Users/dylan/.rvm/gems/ruby-1.9.2-head/gems/chronic-0.2.3/lib/chronic/repeaters/repeater_time.rb:107:in `this' from /Users/dylan/.rvm/gems/ruby-1.9.2-head/gems/chronic-0.2.3/lib/chronic/handlers.rb:318:in `get_anchor' from /Users/dylan/.rvm/gems/ruby-1.9.2-head/gems/chronic-0.2.3/lib/chronic/handlers.rb:90:in `day_or_time' from /Users/dylan/.rvm/gems/ruby-1.9.2-head/gems/chronic-0.2.3/lib/chronic/handlers.rb:178:in `handle_sm_sd_sy' from /Users/dylan/.rvm/gems/ruby-1.9.2-head/gems/chronic-0.2.3/lib/chronic/handlers.rb:193:in `handle_sy_sm_sd' from /Users/dylan/.rvm/gems/ruby-1.9.2-head/gems/chronic-0.2.3/lib/chronic/handlers.rb:44:in `block in tokens_to_span' from /Users/dylan/.rvm/gems/ruby-1.9.2-head/gems/chronic-0.2.3/lib/chronic/handlers.rb:40:in `each' from /Users/dylan/.rvm/gems/ruby-1.9.2-head/gems/chronic-0.2.3/lib/chronic/handlers.rb:40:in `tokens_to_span' from /Users/dylan/.rvm/gems/ruby-1.9.2-head/gems/chronic-0.2.3/lib/chronic/chronic.rb:84:in `parse' from (irb):4 from /Users/dylan/.rvm/rubies/ruby-1.9.2-head/bin/irb:17:in `'
Somewhere between 0.5.0 and 0.6.0 parsing of the format month day, year broke - November 30th, 1985 still works but Chronic.parse("November 30, 1985") now returns nil
uby-1.8.7-p302 > require 'rubygems'
r => true
ruby-1.8.7-p302 > require 'chronic'
=> true
ruby-1.8.7-p302 > Chronic.debug = true
=> true
ruby-1.8.7-p302 > Chronic.parse 'Today'
+---------------------------------------------------
| this(grabber-this) day(repeater-day)
+---------------------------------------------------
-anchor
--(Wed Nov 24 00:00:00 -0800 2010..Wed Nov 24 00:00:00 -0800 2010)
--(Wed Nov 24 00:00:00 -0800 2010..Wed Nov 24 00:00:00 -0800 2010)
=> Wed Nov 24 00:00:00 -0800 2010
ruby-1.8.7-p302 > Chronic.parse 'today at 5pm'
+---------------------------------------------------
| this(grabber-this) day(repeater-day) at(separator-at) 5(repeater-time-18000?, scalar) pm(repeater-dayportion-pm)
+---------------------------------------------------
-anchor
--(Tue Nov 23 00:00:00 -0800 2010..Wed Nov 24 00:00:00 -0800 2010)
--(Tue Nov 23 00:00:00 -0800 2010..Wed Nov 24 00:00:00 -0800 2010)
--(Tue Nov 23 12:00:00 -0800 2010..Tue Nov 23 23:59:59 -0800 2010)
--(Tue Nov 23 17:00:00 -0800 2010..Tue Nov 23 17:00:01 -0800 2010)
=> Tue Nov 23 17:00:00 -0800 2010
ruby-1.8.7-p302 > Chronic.parse 'tomorrow'
+---------------------------------------------------
| next(grabber-next) day(repeater-day)
+---------------------------------------------------
-anchor
--(Wed Nov 24 00:00:00 -0800 2010..Thu Nov 25 00:00:00 -0800 2010)
--(Wed Nov 24 00:00:00 -0800 2010..Thu Nov 25 00:00:00 -0800 2010)
=> Wed Nov 24 12:00:00 -0800 2010
ruby-1.8.7-p302 > Time.now
=> Tue Nov 23 23:43:05 -0800 2010
Chronic.parse("0:00") #=> Wed May 12 12:00:00 +0100 2010
Chronic.parse("00:00") #=> Thu May 13 00:00:00 +0100 2010
I think the first one should become the same as the second
Hi, I was under impression that "2pm" would be translated to tomorrow's 2pm if it is already past the time today and the context is :future. Am I wrong?
ree-1.8.7-2011.03 :054 > Time.now
=> Thu Aug 25 16:51:35 -0400 2011 # it is almost 5pm now
ree-1.8.7-2011.03 :055 > Chronic.parse '8p'
=> Thu Aug 25 20:00:00 -0400 2011 # 8pm today is good
ree-1.8.7-2011.03 :056 > Chronic.parse '2p'
=> Thu Aug 25 14:00:00 -0400 2011 # Wait a second: it is a past date/time, I was expecting a future one
ree-1.8.7-2011.03 :059 > Chronic::VERSION
=> "0.6.2" # I am on this version
ree-1.8.7-2011.03 :060 > Chronic.debug=true
=> true
ree-1.8.7-2011.03 :061 > Chronic.parse '2p'
+---------------------------------------------------
| 2(repeater-time-7200?) pm(repeater-dayportion-pm)
+---------------------------------------------------
-anchor
Handler: handle_r
--(Thu Aug 25 12:00:00 -0400 2011..Thu Aug 25 23:59:59 -0400 2011)
--(Thu Aug 25 12:00:00 -0400 2011..Thu Aug 25 23:59:59 -0400 2011)
--(Thu Aug 25 14:00:00 -0400 2011..Thu Aug 25 14:00:01 -0400 2011)
=> Thu Aug 25 14:00:00 -0400 2011
ree-1.8.7-2011.03 :062 >
Is there any reason for this behavior? This is a bug right?
Chronic.parse("0:10").strftime("%Y-%m-%d %H:%M:%S %p")
"2011-01-19 12:10:00 PM"
Chronic.parse("12:10").strftime("%Y-%m-%d %H:%M:%S %p")
"2011-01-19 12:10:00 PM"
The readme states that Chronic will parse specific dates formatted as "february 14, 2004".
However, the following doesn't work:
Chronic.parse("February 14, 2004") # <= nil
Whereas, whereas parsing without the comma does:
Chronic.parse("February 14 2004") # <= "Fri Dec 10 12:00:00 -0500 2010"
Thoughts?
% ruby -e "require 'time'; require 'rubygems'; require 'chronic'; puts Chronic.parse('24 hours').utc.iso8601"
/usr/local/Cellar/ruby/1.9.2-p136/lib/ruby/gems/1.9.1/gems/chronic-0.3.0/lib/chronic/repeaters/repeater_hour.rb:39:in `this': undefined local variable or method `hour_begin' for repeater-hour:Chronic::RepeaterHour (NameError)
from /usr/local/Cellar/ruby/1.9.2-p136/lib/ruby/gems/1.9.1/gems/chronic-0.3.0/lib/chronic/handlers.rb:399:in `find_within'
from /usr/local/Cellar/ruby/1.9.2-p136/lib/ruby/gems/1.9.1/gems/chronic-0.3.0/lib/chronic/handlers.rb:377:in `get_anchor'
from /usr/local/Cellar/ruby/1.9.2-p136/lib/ruby/gems/1.9.1/gems/chronic-0.3.0/lib/chronic/handlers.rb:270:in `handle_r'
from /usr/local/Cellar/ruby/1.9.2-p136/lib/ruby/gems/1.9.1/gems/chronic-0.3.0/lib/chronic/handlers.rb:77:in `block in tokens_to_span'
from /usr/local/Cellar/ruby/1.9.2-p136/lib/ruby/gems/1.9.1/gems/chronic-0.3.0/lib/chronic/handlers.rb:73:in `each'
from /usr/local/Cellar/ruby/1.9.2-p136/lib/ruby/gems/1.9.1/gems/chronic-0.3.0/lib/chronic/handlers.rb:73:in `tokens_to_span'
from /usr/local/Cellar/ruby/1.9.2-p136/lib/ruby/gems/1.9.1/gems/chronic-0.3.0/lib/chronic/chronic.rb:92:in `parse'
from -e:1:in `<main>'
I noticed odd results when parsing the same string after switching Chronic.time_class to an ActiveSupport time with zone. I've got some ideas of what might be the problem and will update this issue as I explore. Here is some code to show the issue.
require 'rubygems'
require 'chronic'
require 'active_support/time'
s = "8/1/10"
no_as_tc = Chronic.parse(s)
puts no_as_tc.class.name + "\t" + no_as_tc.inspect
Time.zone = "UTC"
Chronic.time_class = Time.zone
yes_as_tc = Chronic.parse(s)
puts yes_as_tc.class.name + "\t" + yes_as_tc.inspect
I am using Ruby 1.9.2.
Almost every text I try to parse, fails with :
/home/antani/.rvm/gems/ruby-1.9.2-p0@rails3tutorial/gems/activesupport-3.0.1/lib/active_support/time_with_zone.rb:316: warning: Time#succ is obsolete; use time + 1
and finally -
undefined method `round' for 18000?:Chronic::RepeaterTime::Tick
ree-1.8.7-2010.01 > Chronic.parse('last week Monday')
=> Tue Nov 02 11:00:00 +0100 2010
I should be Mon not Tue
The numercize_numbers method looks really handy, well beyond working with dates.
http://rubydoc.info/gems/chronic/0.2.3/Chronic
I'd to call it as easily as typing Chronic.parse('tomorrow').
(For example, Chronic.numercize_numbers('eight').
Is something like this possible? Or planned for the gem?
There's some pretty old bugs here. I'd like to know if there's anyone addressing these? Is there a more current fork?
Thanks
Chronic.parse('2009 May 22nd') => '2012-05-22'
Hi ,
It seems like that Chronic.parse("3 months ago") doesn't use Rails built-in time parse function or like that. It seems like Chronic uses 30 days as a unit to calculate months, which is really not good.
Let's say, i.e:
today is 2011/05/30,
well ,using Chronic.parse("3 months ago") will get 2011/03/02( just minus 90 days) , but obviously it is not what we want.
And if you use Rails built-in time support, "3.months.ago" will get 2011/02/28 which is exactly what we want.
Any thought?
Thanks
Parsing 6pm
finds a future time regardless of context
, and so do many or most times without meridiem (6:00
).
>> Time.now
=> Mon Aug 08 09:13:01 -0700 2011
Past parses to 9 hours ahead:
?> Chronic.parse('6pm',:context => :past)
=> Mon Aug 08 18:00:00 -0700 2011
that is, the same as future:
>> Chronic.parse('6pm', :context => :future)
=> Mon Aug 08 18:00:00 -0700 2011
Providing a time with no meridiem parses correctly in the past:
>> Chronic.parse('6:00', :context => :past)
=> Mon Aug 08 06:00:00 -0700 2011
.. but I believe it may be because 6 AM in the past happens to be closer to current time. When I try a different time without a meridiem, it chooses a future one and ignores context
:
>> Chronic.parse('2:00', :context => :past)
=> Mon Aug 08 14:00:00 -0700 2011
All tests with 0.6.2. Thanks.
For example, on the first Sunday of November (Nov 1, 2009)
>> Time.zone = "Mountain Time (US & Canada)"
>> Chronic.time_class = Time.zone
>> Chronic.parse('2009-11-01 12:00:00')
=> Sun, 01 Nov 2009 11:00:00 MST -07:00
which should be the same as the Time.zone.parse(...) function:
>> Time.zone.parse('2009-11-01 12:00:00')
=> Sun, 01 Nov 2009 12:00:00 MST -07:00
Is there a way to change the default of 12 noon for day-based parsing? I've got a business requirement to set that to 00:00:00.
Chronic doesn't seem to like the hours padded with zeros.
Seeing an issue when trying to get the first day of the current month, am I just not writing this correctly? First day of last month and next month seem to work fine.
eg:
ruby-1.9.2-p0 > Chronic.parse '1st day of last month'
=> 2010-12-01 12:00:00 -0500
ruby-1.9.2-p0 > Chronic.parse '1st day of next month'
=> 2011-02-01 12:00:00 -0500
ruby-1.9.2-p0 > Chronic.parse '1st day of this month'
=> 2011-01-11 12:00:00 -0500
Hi using chronic 0.3 in my Rails 3.0.3 project...
It parses dates fine but when I add time into the parse string, i.e., 3pm, 23:59, at 12pm, etc
Chronic generates an exception, the exception looks to be caused by the rails time calculation aliases for +/-
here's the exception:
ruby-1.9.2-p0 > Chronic.parse("12/21/2010 at 2pm")
TypeError: can't convert Chronic::RepeaterTime::Tick into an exact number
from /.rvm/gems/ruby-1.9.2-p0/gems/activesupport-3.0.3/lib/active_support/core_ext/time/calculations.rb:247:in +' from /.rvm/gems/ruby-1.9.2-p0/gems/activesupport-3.0.3/lib/active_support/core_ext/time/calculations.rb:247:in
plus_with_duration'
from /.rvm/gems/ruby-1.9.2-p0/gems/chronic-0.3.0/lib/chronic/repeaters/repeater_time.rb:77:in block in next' from /.rvm/gems/ruby-1.9.2-p0/gems/chronic-0.3.0/lib/chronic/repeaters/repeater_time.rb:74:in
catch'
from /.rvm/gems/ruby-1.9.2-p0/gems/chronic-0.3.0/lib/chronic/repeaters/repeater_time.rb:74:in next' from /.rvm/gems/ruby-1.9.2-p0/gems/chronic-0.3.0/lib/chronic/repeaters/repeater_time.rb:114:in
this'
from /.rvm/gems/ruby-1.9.2-p0/gems/chronic-0.3.0/lib/chronic/handlers.rb:399:in find_within' from /.rvm/gems/ruby-1.9.2-p0/gems/chronic-0.3.0/lib/chronic/handlers.rb:377:in
get_anchor'
from /.rvm/gems/ruby-1.9.2-p0/gems/chronic-0.3.0/lib/chronic/handlers.rb:133:in day_or_time' from /.rvm/gems/ruby-1.9.2-p0/gems/chronic-0.3.0/lib/chronic/handlers.rb:229:in
handle_sm_sd_sy'
from /.rvm/gems/ruby-1.9.2-p0/gems/chronic-0.3.0/lib/chronic/handlers.rb:67:in block in tokens_to_span' from /.rvm/gems/ruby-1.9.2-p0/gems/chronic-0.3.0/lib/chronic/handlers.rb:63:in
each'
from /.rvm/gems/ruby-1.9.2-p0/gems/chronic-0.3.0/lib/chronic/handlers.rb:63:in tokens_to_span' from /.rvm/gems/ruby-1.9.2-p0/gems/chronic-0.3.0/lib/chronic/chronic.rb:92:in
parse'
from (irb):30
from /.rvm/gems/ruby-1.9.2-p0/gems/railties-3.0.3/lib/rails/commands/console.rb:44:in start' from /.rvm/gems/ruby-1.9.2-p0/gems/railties-3.0.3/lib/rails/commands/console.rb:8:in
start'
from /.rvm/gems/ruby-1.9.2-p0/gems/railties-3.0.3/lib/rails/commands.rb:23:in <top (required)>' from script/rails:6:in
require'
from script/rails:6:in `
Using just a date works fine...
ruby-1.9.2-p0 > Chronic.parse("12/21/2010")
=> 2010-12-21 12:00:00 -0600
Is there a way to tell Chronic to NOT use active_support aliases for Time calculations?
Thanks in advance!
I am trying to find a way of getting the last day of a month, for example: last day of last month
I have tried various combos but cannot find anything. I have had a look through the code and it is a bit beyond me. Does anyone know if this can be done?
I should mention that the first day works. Something like "last month first day" or "first day of last month" is fine.
It seems if you try to parse any 1pm time with minutes you get nil. Other times seem to be working with the same format and it only seems to be with pm, am works.
>> Chronic::VERSION
=> "0.4.2"
# Works
>> Chronic.parse '1pm'
=> Wed Jun 08 13:00:00 -0400 2011
# Doesn't work
>> Chronic.parse '1:01pm'
=> nil
>> Chronic.parse '1:32pm'
=> nil
>> Chronic.parse '1:59pm'
=> nil
# Works
>> Chronic.parse '2:01pm'
=> Wed Jun 08 14:01:00 -0400 2011
>> Chronic.parse '1:01am'
=> Wed Jun 08 01:01:00 -0400 2011
First off have to say that I'm loving Chronic.
I just have one request ... would it be possible for Chronic to attempt a Time.parse if its own parsing logic fails?
The reason for asking is based on the following example (with my Time.zone set to 'London'):
Chronic.parse("2011-07-20 10:00:00 +0100")
=> nilTime.parse("2011-07-20 10:00:00 +0100")
=> 2011-07-20 10:00:00 +0100
irb(main):014:0> Chronic.parse("1 year ago", :now => Time.local(2008, 2, 29))
=> 2007-03-01 00:00:00 +0200
irb(main):015:0> Chronic.parse("12 months ago", :now => Time.local(2008, 2, 29))
=> 2007-02-28 00:00:00 +0200
irb(main):016:0> Chronic::VERSION
=> "0.4.3"
and the same test with ActiveSupport:
irb(main):004:0> Time.local(2008, 2, 29).years_ago(1)
=> 2007-02-28 00:00:00 +0200
irb(main):005:0> Time.local(2008, 2, 29).months_ago(12)
=> 2007-02-28 00:00:00 +0200
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.