[Python-Dev] Status on PEP-431 Timezones

Paul Moore p.f.moore at gmail.com
Mon Jul 27 23:19:08 CEST 2015


On 27 July 2015 at 22:10, Tim Peters <tim.peters at gmail.com> wrote:
>> 1. Converting to and from them. That's messy because the conversion to
>> UTC needs more information than just the date & time (typically, for
>> example, there is a day when 01:45:00 maps to 2 distinct UTC times).
>> This is basically the "is_dst" bit that Tim discussed in an earlier
>> post. The semantic issue here is that users typically say "01:45" and
>> it never occurs to them to even think about *which* 01:45 they mean.
>> So recovering that extra information is hard (it's like dealing with
>> byte streams where the user didn't provide details of the text
>> encoding used).
>
> "Flatly impossible" is more on target than "hard".  In the case of
> text encoding, it's often possible to guess correctly by statistical
> analysis of the bytes.  01:45:00 in isolation gives no clue at all
> about whether standard or daylight time was intended.  A similar point
> applies to some ambiguous cases when the base ("standard") UTC offset
> changes.

By "hard", what I meant was that you'd have to explain what you need
to the user, and accept their answer, in the user interface to your
application. Explaining why you need to know in a way that isn't
totally confusing is what I classed as "hard".

I wouldn't even consider trying to guess the user's intent. Although
"if you don't say, I'll use naive datetimes" seems to me a plausible
position to take if you want to allow the user not to care. Strange
that this is how Python works... ;-)

Paul


More information about the Python-Dev mailing list