Message11689
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... |
|
Date |
User |
Action |
Args |
2017-12-07 16:34:48 | stefan.richthofer | set | messageid: <1512664488.06.0.213398074469.issue2647@psf.upfronthosting.co.za> |
2017-12-07 16:34:48 | stefan.richthofer | set | recipients:
+ stefan.richthofer, tmeagher |
2017-12-07 16:34:47 | stefan.richthofer | link | issue2647 messages |
2017-12-07 16:34:46 | stefan.richthofer | create | |
|