如果在某个时刻，epoch是ffffffff，那么此时创建的objectId是这样的:
ffffffff15580625bcb65364
那么，1秒后创建的ObjectId会是什么?
那么，在[Unix纪元以32位滚过]之后创建的ObjectId可能是什么?
这取决于具体的实现，它的编程语言和它们对数学计算的处理。
一些实现和语言可能会在检索自Unix纪元以来的64位整数的秒数时出错(这在今天很常见)，然后尝试使用超过32位的值来生成ObjectId。如果发生这种情况，驱动程序将无法生成objectid，因此它可能无法插入没有_id值的文档，该_id值是由应用程序使用其他生成策略提供的。
在其他实现中，时间戳本身可能滚到0，此时ObjectId生成将成功地使用一个非常小的时间戳值。
然而，其他实现可能会截断时间戳(从最高或最低有效端)以将其强制转换为ObjectId的32位可用位。
objecd值本身实际上没有具有准确的时间戳——它需要在集合中是唯一的，并且它"通常是递增的"。但是MongoDB-the-database不会在意ObjectId值是否在某个点被包装到0左右。
正如docs所说，时间戳是用4字节表示的。
4字节的时间戳值，表示ObjectId的创建，从Unix纪元开始以秒计
4个字节是从-2,147,483,648到2,147,483,647个值，所以，4,294,967,295值。
根据unix时间戳，4294967295中的日期为:GMT: Sunday, 7 February 2106 6:28:15
在此日期之后，ObjectId将无法存储时间戳。
那么，ObjectId可以溢出吗?85年后，每一个新的ObjectId都将失败，因为它无法创建只有4字节的时间戳。