Tighten down locking on datetime tests

[davidhewitt]

After the datetime tests failed again on my machine, I realised that lock!() needs to go before the acquire_gil() call - otherwise released objects can still go into the "wrong" GILPool.

[programmerjake]

From what I can see, the lock!() macro effectively does nothing since each call creates a new mutex then locks it, every function gets it's own new mutex at every call so none of them are shared. what you probably wanted was to lock a global mutex since that may actually do something.

[programmerjake]

The Travis CI failure is caused by parking_lot being updated for the renamed asm -> llvm_asm macro but the nightly compiler being too old to have the macro renamed yet.

[programmerjake]

see rust-lang/rust#68404

[davidhewitt]

Yikes, sorry, you're right about the Mutex, I should have caught that in the original PR. I'll fix this PR and also create one to update the minimum nightly in the morning.

[kngwyu]

From what I can see, the lock!() macro effectively does nothing since each call creates a new mutex then locks it, every function gets it's own new mutex at every call so none of them are shared.

Ah, sorry about that.
Could I open a PR that fixes it myself?

[davidhewitt]

Closed in favour of #867