On 04 Dec 2015, at 5:22 , Sven Van Caekenberghe <sven@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