So my Insights team had a challenge with timestamp data on tweets. Their reporting system was giving them data in users’ timezones and it was not consistent (since timezones are different for different users) and bad for reporting. Their question to me was whether we can have all timestamps converted to the same timezone (preferably EST since the team is here).

The data is actually already available through an API call, and the only task is to convert it to a readable local timezone format.

Here’s how data is coming back from the API call, in UTC zone:

"created_at": "Wed Jun 01 12:53:42 +0000 2011"

Python code:

 #import datetime
 from datetime import datetime
 from datetime import timedelta

 clean_timestamp = datetime.strptime(obj['created_at'],
                   '%a %b %d %H:%M:%S +0000 %Y')
 offset_hours = -5 #offset in hours for EST timezone

 #account for offset from UTC using timedelta                                
 local_timestamp = clean_timestamp + timedelta(hours=offset_hours)

 #convert to am/pm format for easy reading
 final_timestamp =  datetime.strftime(local_timestamp, 
                    '%Y-%m-%d %I:%M:%S %p')  

Had another great question in the M102 forums a few days ago, so wanted to share it, since I didn’t know the exact answer, and Dwight graciously clarified it for everyone.

Question:

• If I have admins and users with read/write or read only access on the primary node, will that info transfer to secondary nodes?
• Can we have different admins for different nodes of mongo?

My initial thinking went like this:

The user info is stored in the system.users database (where all user credentials are stored), so with replica sets it would be replicated across all nodes and allow access to data from any node. And since the info would be copied across all nodes, I don’t think it’s possible to have different admins for different nodes.

Dwight’s explanation with example:

The auth information replicates, so you either have authorization for the set as a whole, or not. The auth is per database (with authorization on the ‘admin’ database implying you can access all).

So you could do something like this:

$ mongo –host abc8
 use mydb
 db.system.users.find()
 ^C
 $ mongo –host abc9
use mydb
rs.slaveOk()
db.system.users.find()

And you should see the same user information (assuming the secondary is caught up to the replication time of the user additions).

The above example is for a standalone replica set; if you are sharded you would connect to the cluster through mongos. Once again your credentials are for the whole cluster, per db.

Additional resources and notes:

More information on authentication: http://docs.mongodb.org/manual/tutorial/control-access-to-mongodb-with-authentication/

Note that for replica sets you’ll need to use –keyFile option to specify configuration file that will be used to authenticate between members of the replica sets: http://docs.mongodb.org/manual/administration/replica-sets/#replica-set-security