<div><br></div><br>On Sunday, August 16, 2015, Alexander Belopolsky <<a href="mailto:alexander.belopolsky@gmail.com">alexander.belopolsky@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">PEP 495 [1] is a deliberately minimalistic proposal to remove an<br>
ambiguity in representing some local times as datetime.datetime<br>
objects.</blockquote><div><br></div><div>I'm quite confused - I though that all this discussion about terminology ended with agreement that the current datetime object is a good representation of naive time (aka LocalDateTime in other libraries). That time is never ambiguous because it has no timezone to begin with.</div><div><br></div>I'm also not sure what purpose adding this flag to time object has. I know it has a tzinfo, but it's obviously impossible to have a dst aware implementation working with that. <br><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The concept has been extensively discussed on python-ideas and this<br>
mailing list.  I believe a consensus has been reached and it is<br>
reflected in the PEP.</blockquote><div><br></div><div>A middle of summer vacations is not the best time to reach a consensus on anything ;) I'm not asking for special treatment, but as Python 3.6 is months away, maybe this could wait a week or two more.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
PEP 495 does not propose any changes to datetime/timedelta<br>
arithmetics, but it has been agreed that it is a necessary step for<br>
implementing the "strict" rules.</blockquote><div><br></div><div>Without a clear view what are the next steps with this approach, I think it might harm the final solution because it introduces even more things to be backward compatible about.</div><div><br></div><div>----</div><div><br></div><div>I would like to propose an alternate solution. Instead of a flag, I propose to add a "zone offset" property. This would be a read-only property that is assigned by tzinfo when converting to that timezone (and possibly when doing arithmetic). </div><div><br></div><div>This solves the problem of overlapping moments, doesn't depend on the gap being 60 minutes or having external knowledge about it and allows for simple convention to UTC.</div><div><br></div>Instead of adding more arguments to constructor and replace(), I propose add two methods to datetime:<div><br></div><div>  * earlier_when_overlap()</div><div>  * later_when_overlap()<br><div> </div>That would delegate to tzinfo the task to produce a datetime instance that matches the requested moment in time. When parsing strings, earlier would be always chosen and user can adjust to their preference. For all current implementations those would be a no-ops.</div><div><br></div><div>I hope this actually makes any sense to you. I don't have such great writing skills to produce a PEP so quickly (especially on a phone). If no, just ignore this message ;)</div><div><br></div>Best regards,<div>Łukasz<br><div><br></div><div><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
[1]: <a href="https://www.python.org/dev/peps/pep-0495" target="_blank">https://www.python.org/dev/peps/pep-0495</a><br>
_______________________________________________<br>
Datetime-SIG mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'Datetime-SIG@python.org')">Datetime-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/datetime-sig" target="_blank">https://mail.python.org/mailman/listinfo/datetime-sig</a><br>
The PSF Code of Conduct applies to this mailing list: <a href="https://www.python.org/psf/codeofconduct/" target="_blank">https://www.python.org/psf/codeofconduct/</a><br>
</blockquote></div></div><br><br>-- <br>Łukasz Rekucki<br>