[Datetime-SIG] PEP 495 (Local Time Disambiguation) is ready for pronouncement

[Łukasz Rekucki]

On Sunday, August 16, 2015, Alexander Belopolsky <
alexander.belopolsky at gmail.com> wrote:

> PEP 495 [1] is a deliberately minimalistic proposal to remove an
> ambiguity in representing some local times as datetime.datetime
> objects.


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.

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.


>
> The concept has been extensively discussed on python-ideas and this
> mailing list.  I believe a consensus has been reached and it is
> reflected in the PEP.


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.


>
> PEP 495 does not propose any changes to datetime/timedelta
> arithmetics, but it has been agreed that it is a necessary step for
> implementing the "strict" rules.


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.

----

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).

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.

Instead of adding more arguments to constructor and replace(), I propose
add two methods to datetime:

  * earlier_when_overlap()
  * later_when_overlap()

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.

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 ;)

Best regards,
Łukasz



> [1]: https://www.python.org/dev/peps/pep-0495
> _______________________________________________
> Datetime-SIG mailing list
> Datetime-SIG at python.org <javascript:;>
> https://mail.python.org/mailman/listinfo/datetime-sig
> The PSF Code of Conduct applies to this mailing list:
> https://www.python.org/psf/codeofconduct/
>


-- 
Łukasz Rekucki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150817/bd1fd80d/attachment.html>