Then why not introduce a MongoTimestamp and be done with it ?
> On 04 Dec 2015, at 17:41, Henrik Johansen <henrik.s.johan...@veloxit.no>
> wrote:
>
>
>> On 04 Dec 2015, at 5:22 , Sven Van Caekenberghe <s...@stfx.eu> wrote:
>>
>> According to http://bsonspec.org/spec.html there are indeed 2 different types
>>
>> "\x09" e_name int64 UTC datetime
>>
>> "\x11" e_name int64 Timestamp
>>
>> I would guess that you need 2 different (sub)classes in Pharo if you want to
>> honour this spec. It has little to do with the almost empty TimeStamp
>> subclass of DateAndTime having been removed. This is an API design issue
>> (decide on the Pharo to BSON type mapping).
>
> Strictly speaking, Timestamp should've never been mapped;
> "Timestamp - Special internal type used by MongoDB replication and sharding.
> First 4 bytes are an increment, second 4 are a timestamp"
> doesn't exactly agree with the smalltalk implementation:
> nextTimestampPut: aTimestamp
> self nextDateAndTimePut: aTimestamp
>
> It's a problem when an existing application stored Timestamp instances with
> the broken type, for the reason I explained.
> I'd be fine with having a legacy-compatibility package containing Timestamp
> class + bson extensions as before (even though it was broken) strictly for
> use when migrating legacy applications.
>
> That's what we have Monticello groups for, right? ;)
>
> Cheers,
> Henry
