Message11689

Author stefan.richthofer
Recipients stefan.richthofer, tmeagher
Date 2017-12-07.16:34:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1512664488.06.0.213398074469.issue2647@psf.upfronthosting.co.za>
In-reply-to
Content
Okay, shortly speaking Py.newDatetime and __tojava__ on the result should be conversion-compatible. That sounds reasonable to me.

However, we must consider that there might be code out there that is "bug-compatible" to the current behavior and changing Py.newDatetime would not be backwards compatible.

I would suggest the following:
- implement your fix as Py.newDatetimeUTC
- overload Py.newDatetime with a version that explicitly takes a time zone as second argument
- deprecate the original Py.newDatetime because it is incompatible with __tojava__ of datetime objects
- clarify and warn about this in javadoc of Py.newDatetime

@Tim Thanks for finding and working on this issue! Feel free to ask questions if you're stuck or add a PR at github to discuss your approach...
History
Date User Action Args
2017-12-07 16:34:48stefan.richthofersetmessageid: <1512664488.06.0.213398074469.issue2647@psf.upfronthosting.co.za>
2017-12-07 16:34:48stefan.richthofersetrecipients: + stefan.richthofer, tmeagher
2017-12-07 16:34:47stefan.richthoferlinkissue2647 messages
2017-12-07 16:34:46stefan.richthofercreate