[Datetime-SIG] Computing .dst() as a timedelta

[Chris Angelico]

On Wed, Sep 23, 2015 at 12:53 PM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> On Tue, Sep 22, 2015 at 10:27 PM, Chris Angelico <rosuav at gmail.com> wrote:
>>
>> (With the
>> possible exception that different states of the US can probably cheat,
>> since there's federal US legislation about DST. But if your examples
>> were New York and Sydney, then my point stands.)
>
>
> What would be your guess for the ratio between the number of calls between
> New York and say San Francisco to that between New York and Sydney?   For
> the latter, I'll concede: UTC makes sense because it is somewhere in the
> middle. :-)

Heh. It's not really a matter of being in the middle, though - I would
advocate UTC for any recurring event that involves different DST
rules. UTC isn't mid-way between, say, Sydney and Warsaw, but if you
want to phone someone in the opposite hemisphere every week, it'd be
best to schedule it in UTC so you don't have to worry about four
different offsets (you could both be on DST, or either of you could,
or neither).

Of course, if DST were abolished world-wide, then everything would be
easy, and we could happily schedule things in each other's timezones
without any confusion. I could key in "11PM" and the program would
interpret that as being UTC+10, and then my friend in Florida could
see it as "9AM", and nobody would be confused at all. Alas, I fear
'tis a vain hope...

ChrisA