Fix datetime deserialization for timezone aware fields

[buchi]

Fixes #253

[coveralls]

Coverage increased (+0.01%) to 96.576% when pulling 51bec0b on fix-datetime-deserialization into 88a6779 on master.

[buchi]

@sneridagh I've implemented another approach to fix datetime deserialization. Can you check if this works for your use case?

If the field already has a value, the new value will be converted to a timezone aware datetime object with the same timezone. This works also for newly created events as the start and end field both have default values.
If the field doesn't have a value, the given value is stored as datetime naive object (same behavior as before).

[coveralls]

Coverage increased (+0.01%) to 96.576% when pulling 4c810cb on fix-datetime-deserialization into 88a6779 on master.

[coveralls]

Coverage increased (+0.01%) to 96.576% when pulling 4c810cb on fix-datetime-deserialization into 88a6779 on master.

[coveralls]

Coverage increased (+0.01%) to 96.576% when pulling 4c810cb on fix-datetime-deserialization into 88a6779 on master.

[tisto]

LGTM. Would like someone else with more in-depth knowledge to have a second look (e.g. @sneridagh )

[coveralls]

Coverage increased (+0.01%) to 96.576% when pulling b40c992 on fix-datetime-deserialization into 7fa16c9 on master.

[coveralls]

Coverage increased (+0.01%) to 96.576% when pulling b40c992 on fix-datetime-deserialization into 7fa16c9 on master.

[coveralls]

Coverage increased (+0.01%) to 96.65% when pulling e559c10 on fix-datetime-deserialization into 8a84333 on master.

[tisto]

@sneridagh could you please review this pr? I would like to make a new release soon and include this one if possible.

[coveralls]

Changes Unknown when pulling 9487194 on fix-datetime-deserialization into ** on master**.

[coveralls]

Changes Unknown when pulling 9487194 on fix-datetime-deserialization into ** on master**.

[coveralls]

Coverage increased (+0.01%) to 96.651% when pulling 9487194 on fix-datetime-deserialization into c9be8e3 on master.

[coveralls]

Coverage increased (+0.01%) to 96.654% when pulling f7a7f21 on fix-datetime-deserialization into 3aaf76e on master.

[sneridagh]

LGTM too! Nice and elegant approach that fixes all the use cases and retains the current behavior.

@tisto @buchi:
However, I implemented some tests in my initial PR that might be interesting:

https://github.com/plone/plone.restapi/pull/394/files#diff-a6bae0e634bde0c6823c506071a52a50R224

and

https://github.com/plone/plone.restapi/pull/394/files#diff-03b868ff4d32963d159a2f06dcbe9588R93

They are working fine but have the drawback that they must be especific for p.a.event <2.0 and above that. Do you think they are interesting to have in place or we can live without them?