Notice: Undefined property: stdClass::$timestamp in _drupal_session_write()

It looks to me like this patch just suppresses the warning

But the $user->timestamp value is not set and as well as any other issues this degrades performance - by failing to restrict saves to the session table as the comment indicates should happen

I think that applying the patch individually to avoid clogging logs may be OK but I wouldn't want this patch in core - the underlying problem needs to be resolved.

When should $user->timestamp be set? It looks to come from the $_SESSION rather than the original account object but I don't fully understand how that gets merged into the user object.
To be honest, whether there is an underlying issue or not, I think it is correct to add a check for $user->timestamp, since if this function is abstracted away from the rest of core, it shouldn't matter if the timestamp is not set - the session should always get updated if this is the case whatever the reason, and a PHP notice is unnecessary.
Wherever the underlying cause is though, that probably does also need identifying and a perhaps a more descriptive notice/warning thrown up there.

For reference, this issue is also being covered here: #1078614: Notice: Undefined property: stdClass::$timestamp in _drupal_session_write(). One of these issues should be marked as a duplicate.

Marking this issue as duplicate -- I've referenced this discussion over at #1078614: Notice: Undefined property: stdClass::$timestamp in _drupal_session_write().

@seanburlington Please weigh in over at that other issue to help progress this issue if you want to.