Is this a bug? View index with a big int fails badly at some value threshold.

This is all assuming DP4 on CentOS 5.8:

Given sample doc structure:

{
"_id": "0830c075-2a81-448a-80d6-85214ee3ad64",
"_rev": "1-0015b2c01f0a39310000023f00000000",
"$flags": 0,
"$expiration": 0,
"docId": "0830c075-2a81-448a-80d6-85214ee3ad64",
"conversationId": "0c872a9ba58143119d477850a5c02ac3",
"timeStamp": 13403751757202,
"msg": "\r\nvery clearly revealed something unexpectedly coarse and unpleasant.\r\n\r\n\"And why are children born to such men as you? If you were not a father\r\nthere would be",
"status": "If you don't have a nasty obituary you probably didn't matter.\n\t\t-- Freeman Dyson\n",
}

Also note there are a bunch of records milliseconds later than this one.

Given view function:

function (doc) {
emit([doc.conversationId, doc.timeStamp], doc);

With the following two "filter results":
?endkey=["0c872a9ba58143119d477850a5c02ac3",13990000000000]&startkey=["0c872a9ba58143119d477850a5c02ac3",13403751757202]&limit=10&skip=0
?endkey=["0c872a9ba58143119d477850a5c02ac3",13900000000000]&startkey=["0c872a9ba58143119d477850a5c02ac3",13403751757202]&limit=10&skip=0

With the first filter result I get my 10 records back. In the second case I get this result:

{"error":"query_parse_error","reason":"No rows can match your key range, reverse your start_key and end_key or set descending=true"}

Note the only change in the two filter results is changing the one '9' to a '0' in the endkey timeStamp value. With all the stored documents for this conversationId crowded around the startkey timeStamp, both these should have returned the same thing.

Before I post this as a bug, does this sound like a bug or am I coming up on some kind of numeric threshold or some other restriction that I should, but do not know about? Even at that, seems like if an integer is overflowing or something there should be an error indication, no? For now would we have better results if we store the timestamp as a string value?