[Datetime-SIG] Local time disambiguation proposal
alexander.belopolsky at gmail.com
Tue Aug 4 18:06:53 CEST 2015
On Tue, Aug 4, 2015 at 2:14 AM, Tim Peters <tim.peters at gmail.com> wrote:
> [Alexander Belopolsky]
>> ... make sure that you've read the latest version.
>> : https://github.com/abalkin/ltdf/blob/master/README.rst
> Since that appears to be obsolete now, here are some comments on:
I made README.rst a symbolic link to pep-0495.txt, so the PEP will get
rendered on the main project page:
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:
> 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.
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:
> Instances of ``datetime.time`` and ``datetime.datetime`` classes that
> differ only by the value of their ``first`` attribute will compare as
> 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 ;-)
More information about the Datetime-SIG