On Tue, Aug 4, 2015 at 2:14 AM, Tim Peters <[email protected]> wrote: > [Alexander Belopolsky] >> ... make sure that you've read the latest version. >> >> [1]: https://github.com/abalkin/ltdf/blob/master/README.rst > > Since that appears to be obsolete now, here are some comments on: > > https://github.com/abalkin/ltdf/blob/master/pep-0495.txt > > instead.
I made README.rst a symbolic link to pep-0495.txt, so the PEP will get rendered on the main project page: https://github.com/abalkin/ltdf Unfortunately I cannot make the old link work as before. > > """ > The ``replace()`` methods of the ``datetime.time`` and > ``datetime.datetime`` classes will get a new keyword-only argument > called ``first`` with the default value ``True`` > """ > > That's dubious: .replace() treats all other missing arguments as > meaning "copy this attribute's current value". I don't see why > `.first` should be different. Right. I updated the text: https://github.com/abalkin/ltdf/commit/2fa9e6bfeefec61bf642bec658149ba55a348982 > """ > The ``timestamp()`` method of ``datetime.datetime`` will return value > advanced by 3600 if ``self`` represents an ambiguous hour and > ``first`` is False. > """ > > Are all known DST adjustments, and changes to standard UTC offsets -- > in, say, zoneinfo -- exactly one hour? For example, I read this on > the web, so it must be true: "Lord Howe Island (Australia) advances > its clocks by half an hour in the summer" ;-) Since I expect we > expect to support all the goofy timezones in zoneinfo, best to get > that right from the start. I agree. In addition to your example, I found some cases where standard time was rolled back: Date Time Zone Offset_before Offset_after 1942-01-28 16:30:00 Asia/Pontianak 9.0 7.5 1942-02-15 16:30:00 Asia/Kuala_Lumpur 9.0 7.5 1942-02-15 16:30:00 Asia/Singapore 9.0 7.5 1942-03-22 16:30:00 Asia/Jakarta 9.0 7.5 1942-04-30 17:30:00 Asia/Rangoon 9.0 6.5 1942-08-31 18:30:00 Asia/Dacca 6.5 6.0 1942-08-31 18:30:00 Asia/Dhaka 6.5 6.0 1944-08-31 15:00:00 Asia/Jayapura 9.5 9.0 1945-09-07 15:00:00 Asia/Seoul 9.0 8.5 1945-10-14 17:30:00 Asia/Karachi 5.5 5.0 1948-04-30 16:30:00 Asia/Jakarta 8.0 7.5 1948-04-30 16:30:00 Asia/Pontianak 8.0 7.5 1950-04-30 16:00:00 Asia/Jakarta 7.5 7.0 1965-01-01 04:30:00 America/Caracas -4.0 -4.5 1965-10-31 04:30:00 America/Goose_Bay -3.5 -4.0 1978-10-20 19:00:00 Asia/Tehran 4.0 3.5 1996-05-24 18:30:00 Asia/Colombo 6.5 6.0 1996-10-25 18:00:00 Asia/Colombo 6.0 5.5 I think, for practical purposes we will allow implementations without direct access to the timezone data to assume that "folds" can only happen on a 15 min boundary and be a multiple of 15 min in duration, but I rewrote that section now. https://github.com/abalkin/ltdf/commit/aa63f7d313ad245c7ca1e8713b07a8799112a6f5 I agree with your remaining points and will update the PEP accordingly. > > """ > The value of "first" will be ignored in all operations except those > that involve conversion between timezones. > """ > > "Involve" is vague. Subtraction and comparison can "involve" > conversion to UTC, at least conceptually, when two datetimes don't > share a tzinfo member. It's explicitly stated later that: > > """ > Comparison > ---------- > Instances of ``datetime.time`` and ``datetime.datetime`` classes that > differ only by the value of their ``first`` attribute will compare as > equal. > """ > > but it's not explicitly stated that subtraction of such instances will > return timedelta(0). If there's a reason to explicitly point out one, > then both should be mentioned, since comparison actually inherits its > behavior from subtraction. > > The real reason the cases named will always compare as equal is that > they share a common tzinfo member (or both have none). That > short-circuits the conceptional conversion to UTC before comparison. > But if you plug a workalike tzinfo member into one of them (same > timezone represented by a distinct tzinfo object), then the results of > comparison (and subtraction) _may_ change "just because" .first > differs between them. That all depends on what .utcoffset() returns. > > In the text about comparisons, I expect you're just trying to say that > .first isn't used as a tie breaker, as if datetime comparisons were > akin to tuple comparisons, comparing field by field. But that's not > how it's done, and there's no real point to explaining how a model > that didn't apply to begin with would be affected if it had applied to > begin with ;-) > > So I'd drop the text about comparisons. But I'd add some text > explaining that, while this PEP isn't aiming at timeline arithmetic, > some cases of subtraction and comparison, which have used timeline > arithmetic all along, will return different results now due to > .utcoffset() returning different results now. To make the reader > happy, you could even mention that these different results are also > correct now ;-) _______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
