Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Should created_at always be a time? #361

dpzmick opened this Issue · 12 comments

3 participants


I've been creating hashes of tweets using tweet.attrs, and I noticed that the created_at value returned when attrs is access is a String, not a Time.

Looking at the code for creatable, it is pretty clear that the "created_at" string is only parsed to a Time if created_at is called.

This is somewhat problematic for me as I am pulling Tweets using the streaming API, then using the hash representation the Tweets generate to store them in Mongo.

Would it be possible to store the "created_at" attribute of creatables as a Time instead of requiring a function call to make it one?


I should probably mention that I am using the TweetStream to gather the tweets.


I also should mention that I am accessing the attributes using the hash returned by Tweet::attrs

@sferik sferik closed this in ff4f2da

Try version 4.6.0.


Fantastic! Thank you!


Actually. I am not sure this entirely fixes the problem.

Only the first occurrence of "created_at" is held as a date. Additionally :user now points to a user object, not a hash.


@dpzmick Perhaps you could work on a patch that solves this problem to your satisfaction.


I forked and played with the code for a while. I did manage to get the behavior I want, but my code is terrible and only works in my specific case. Would you recommend that I continue trying to get this to work or would it be better to revert to the previous state (in which case I will deal with dates myself)?

I can keep attempting to get to a solution if you think this behavior is desired, otherwise I would prefer to have the initial behavior back (sorry to be a bother :/ )


Would you mind describing your actual use case. I'm not sure I fully understand it.


I would like to be able to get a hash from Twitter objects that has meaningful ruby core objects in it.

Before you made any changes, Base::attrs returned a hash in the form I am looking for, but values in the hash were either fixnums, strings, or another hash. I feel like the values for keys like "created_at" should be meaningful ruby objects ("created_at" => Time) anytime they shows up in a hashed representation of an object.

But, I do not want these hashes to contain other twitter objects. So, your solution would work if it continued to create hashes from any other twitter objects it hits along the way. I tried doing this but could not resolve the recursive hell I got myself in without nasty hacks.

I'm not sure how much this helps, but here is an example of what I would like to see (pretty much the same as the original output, but created_at always has a Time object for it's value)


I'm :-1: on this concept. Reason being is there are defaults in some of the convenience methods in some of the Twitter objects. Take the User object for example:

def profile_banner_url_https(size=:web)
  [@attrs[:profile_banner_url], size].join('/') if profile_banner_url?

What you get from user.attrs is not the same as a raw response which it sounds like is closer to what you are after, with some exceptions (dates). I also wonder if some of this could be better handled via an accessor method on your model:

class MyModel
  include Mongoid::Document

  def created_at=(t)
    @created_at = t.kind_of?(Time) ? t : Time.parse(t)

I noticed in your comment above that nested classes were not being converted properly and fixed that in #364. But I think the general approach should be up for debate. I'm in favor of letting attrs just return a hash as it was before.


I see what you mean. I realized earlier today that it becomes difficult to decide what should be returned as an object and what should be returned raw. Should a URL be returned as a ruby URI? I would say no, but I realize that I am asking for that kind of behavior in the case of dates.

So, I would second you vote to have attrs return a hash as it was before.


It looks like this change is causing an issue #368, so I'm going to revert it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.