mad.ly rails, jquery, flash, etc    about »

Making Rails time zone aware attributes and Chronic play well together

I came up with this monkeypatch to Time.zone.parse, so that it uses the Chronic time parsing library instead of Time.parse:

…with this in place, I can assign natural language date/time strings to model attributes, and the values will be parsed in the current Time.zone:

I’m confused … where does this patch go?
Thanks.

@Ed, the easiest thing to do is to put this code into a file (named time_zone_parse_with_chronic.rb, or whatever you like) in the config/initializers directory.

Keep up the good work!

Hmm. Good post.

Geof,

I just found your blog. Thanks for all the helpful timezone info.

Related to this post, I’m curious how you do you handle certain parsing issues with Chhronic. In an application that I work on, I added some logic similar to this:

t = Chronic.parse(str)
if t.nil?
t = Time.parse(str)
end

That logic isn’t great because Chronic doesn’t know how to parse strings like “11/02/2008 01:20 PM” (it returns nil), yet Time.parse defaults to Time.now when parsing strings like “asdf” (which the ruby core team says is on purpose: http://redmine.ruby-lang.org/issues/show/281). It seems like Chronic.parse should be able to handle it all. I thought you might have run into some of this before.

Thanks for the post, I have been having the same problems.

@Jeff –

1. Time.parse treating unknown strings as Time.now is annoying and, imo, useless behavior — which is why I made Rails’ Time.zone.parse just return nil when it doesn’t understand input.

2. looks like Chronic fails to recognize “11/02/2008 01:20 PM” because of the leading zero on the hour — the existence of such cases is probably a good argument for layering Chronic parsing on top of TimeZone#parse via alias_method_chain, versus re-implementing it.