7ac33e16 introduces the following behaviour on Zope4.

• code

portal = context.getPortalObject()
web_page = portal.web_page_module.newContent(
  portal_type='Web Page',
  temp_object=True,
)
web_page.setEffectiveDate(DateTime(0))
print web_page.getEffectiveDate()
print web_page.hasEffectiveDate()
return printed

• Zope2 result

1970/01/01 01:00:00 GMT+1
True

• Zope4 result

None
False

It is caused by DateTime.equalTo at https://github.com/zopefoundation/DateTime/commit/b9ddd8b9f9c8ba89fcab749a1871871706e7c2c0#diff-778daecbfbef655fab523b4aaa62847e40260011204ee3202a063367e3f35f91R1247 and Setter.__call__ at https://lab.nexedi.com/nexedi/erp5/blob/7ac33e16956cbd4684fdefbf35d25fcfff39350f/product/ERP5Type/Accessor/Base.py#L74-75 (and similar code in Tester.__call__).

I can understand that the change in DateTime is introduced for Python3 sorting, but I think the code should be rather the following to keep Python2's sort behaviour, i.e. None is always first.

def equalTo(self, t):
  if t is None:
    return False # instead of 't = 0'
  ...

def greaterThanEqualTo(self, t):
  if t is None:
    return True # instead of 't = 0'
  ...

def lessThanEqualTo(self, t):
  if t is None:
    return False # instead of 't = 0'
  ...

I posted an issue on upstream at https://github.com/zopefoundation/DateTime/issues/52

This MR is to fix this issue in our DateTime patch level.

/cc @jerome