settings from zope.conf. Because getConfiguration().datetime_format
can be expensive we provide a method getDefaultDateFormat() that
cache the value once retrieved from the configuration machinery.
Ugly (as the DateTime module) but it works.

Removing the import and call allows the tests to pass.

This code is a complete mystery.  It wasn't failing when I ran the
tests yesterday.  But if I do a checkout -D "yesterday," it fails with
an error on the Zope.startup() call.  It looks like that code should
have always failed.  No idea how it ever worked.

that these tests can fail for bogus reasons.  Jeremy saw them failing
today, and it took a while to figure out that this had nothing to do with
the ZODB changes he was making.

We'd like to deprecate explanation manipulation of a Persistent
object's _p_jar attribute.  Also use less obscure _p_deactivate()
call.

Revise comments and add assertions that object is stored and ghosted.

you to use scripts which require arguments under zopectl run.

If you do "zopectl run scriptname.py arg1 arg2", the value of sys.argv within the script will consist of ['scriptname.py', 'arg1', 'arg2'].

test_monitor_factory_with_emergency_user:  Two more that failed on
Windows, and still do, but later now.

and still fail, but later now.

but fails later now.

way it failed on Windows, only to uncover another way it fails on Windows.

        self.assertEqual(factory.host, '')

test to something else failing in

        self.check_prepare(factory)

The failure now is check_prepare's

   self.assertEqual(factory.host, "127.0.0.1")

factory.host is actually 'localhost' on Windows, but I don't understand
this test so am stopping now (and it still fails on Windows).

Add support for persistent weak references.  The implementation is in
pure Python right now; coptimizations.c was disabled.  We need to
restore the C code before going to beta.

The persistent reference format has evolved a little, but the code on
the branch doesn't document it.  The ref is usually a an oid-class
pair, where the class is an actual class object.  It can also be a
list, for weak references, or a bare oid.

Add support for data managers written against the ZODB4 transaction
API.  The transaction implementation provides an adapter between the
two interfaces.  There's a substantial doctest test suite for this
feature.

Add add() method to Connection to explicitly add an object and get it
an assigned _p_oid.  It's possible to add an unconnected object; this
isn't recommended, because it will be lost at pack time.

The storage was added to these repositories hoping that that would
encourage people to test it. The storage is not (yet) usable in
production due to Berkeley DB log handling problems.  The storage is
a constant source of irritation due to errors in implicit algorithms
to decide whether to build BDB extensions when building Python and
due to implicit algorithms used to decide whether the BDB extension
was suitable for use by the storage when running tests.  The BDB
storage tests are also rather time consuming.

The final straw was the recent ZODB change that caused many BDB
storage tests to fail. :(

imPermissionRole to be consistent with Python code.

string roles only of the values were different. This was a needless
optimization. Then we preceeded to reset the roles value even though
it wasn't used again.

When Implementation.py set the default policy, it set the
_implementation_set flag, preventing further changes.  Also,
Zope.Startup.run.configure() was not applying the security options.