I'd prefer users not to use the existing Date and DateTime expressions
directly. They really are internal, and were moved from elsewhere.
Small wrapper expressions could use them internally though. That's what I'd
prefer to see I think. Thoughts?
On Sunday, 3 May 2015 01:53:21 UTC+10, Michał Mo
Hi Carl,
2015-04-13 21:11 GMT+02:00 Carl Meyer mailto:c...@oddbird.net>>:
It would also be possible to put the silent-data-loss aspect of this
change through a deprecation path, by having the existing adapters raise
a deprecation warning on receiving any non-UTC aware datetime for a
couple release
Shai,
Thanks for the note.
I thought about what you wrote a bit. I find your points compelling. I
don't like the consequences of my proposed changes in terms of:
1. Error handling. The exceptions would be raised at the end of the
transaction block and there's no simple way to handle them excep
> On 3 maj 2015, at 15:44, Christopher Adams
> wrote:
>
> So unless anyone has objections, I'm going to put my branch on hold for now.
> If anyone still wants me to see if there's a way it can work I'm willing to
> give it a bit more work, however I think it should probably be passed over
>
