> On 27 jul. 2015, at 20:49, Tim Peters <tim.pet...@gmail.com> wrote: > > [Ronald Oussoren <ronaldousso...@mac.com>] >> IMHO “+ 1 days” and “+ 24 hours” are two different things. >> Date arithmetic is full of messy things like that. > > But it's a fact that they _are_ the same in naive time, which Python's > datetime single-timezone arithmetic implements: > > ... > > Naive time is easy to understand, reason about, and work with. When > it comes to the real world, political adjustments to and within time > zones can make the results dodgy, typically in the two DST-transition > hours per year when most people living in a given time zone are > sleeping. How much complexity do you want to endure in case they wake > up? ;-) Guido's answer was "none in arithmetic - push all the > complexity into conversions - then most uses can blissfully ignore the > complexities".
I totally agree with that, having worked on applications that had to deal with time a lot and including some where the end of a day was at 4am the following day. That app never had to deal with DST because not only are the transitions at night, the are also during the weekend. Treating time as UTC with conversions at the application edge might be "cleaner" in some sense, but can make code harder to read for application domain experts. It might be nice to have time zone aware datetime objects with the right(TM) semantics, but those can and should not replace the naive objects we know and love. That said, I have had the need for date delta objects that can deal with deltas expressed at days or months but it is easy enough to write your own library for that that can deal with the local conventions for those. Ronald _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
