Nathan

`force` sounds good. Regarding your other point - this would mean that the user would have to call set twice if they don't want to set all the data using...

@mickhansen Basically, I have entities being created + updated in an offline context. When the application syncs with the online API, assuming everything is a-okay, I want to retain the...

@mickhansen I have an implementation running but it isn't necessarily 10000% ideal as it requires the option is passed to both set and save if you call them separately. (If...

@mickhansen Not working for me. Something interesting to note though, consider the following test: ``` js it('updates timestamps when passing forceTimestamps=true', function() { var self = this; return this.User.create({ username:...

@mickhansen Ignore the name of the option as it's currently `manualUpdate` (from before we spoke in this thread) https://github.com/sequelize/sequelize/compare/master...nathanmarks:manual-updatedat As a side node, in the test I embedded inline above,...

@mickhansen The issue isn't a promise being returned (most of my JS apps involve promise consumption, usually with a heavier sprinkling of rejection than sequelize though) -- it just seems...

@mickhansen want a PR with a failing test when checking the attributes of an instance returned from `save` then? Right now for a workaround I'm going to rebase my branch...

@mickhansen Let me know if you want to see a proof of concept for the `raw` array option, I think it's an interesting way around your concern of adding an...

@mickhansen I'll submit a failing test for that separate issue and put together a PR for the timestamp conundrum! Totally understand if you're on the fence and not sure --...

@josephsavona Is this why I'm running into some weird issues where sometimes istanbul is not instrumenting the code properly? I'm seeing statements, functions, etc just not even getting recognized full...