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

[Chris Angelico]

On Wed, Sep 23, 2015 at 12:16 PM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
>
> On Tue, Sep 22, 2015 at 8:57 PM, Chris Angelico <rosuav at gmail.com> wrote:
>>
>> [ Alexander Belopolsky] I bet people in Russia who know what
>>
>> > Moscow time is outnumber those who know what UTC is at least 100 to 1.
>> > I
>> > bet you will get a similar ratio in California between UTC and say
>> > Eastern
>> > Standard Time.
>>
>> Of course. Local time is always better known than UTC.
>
>
> Moscow Time is hardly local for Russian Anadyr or Petropavlovsk-Kamchatsky,
> but people still use Moscow Time for train schedules there.  In fact, those
> places are closer to California than they are to Moscow.

"Close" doesn't necessarily have anything to do with geographic
location. I'm fairly sure Troll Research Station isn't physically
close to Norway, but when it's being operated solely by Norwegians,
it's politically very close. I've no idea how the trains operate, but
it's a lot more likely that they're politically near Moscow than
California.

>> I would bet
>> that the people in Russia who know Eastern Standard Time, or the
>> people in California who know Moscow time, would be quite low.
>
> I suspect that anyone who knows about UTC would know about both Moscow and
> New York.

Know about, yes, but they won't necessarily know the DST rules etc.

>> > Let's have a show of hands here: how many people know what "C" stands
>> > for in
>> > UTC and what "M" stands in GMT and what is the significance of these
>> > letters?
>>
>> I know, on both counts, because I'm a wonk.
>
> Well, in this case you know more than I do.  I know that "M" stands for
> "mean" (I've heard that on BBC:-) and that it has something to do with the
> solar time, but I cannot tell you "mean" of what it is or whether BBC's
> fifth beep comes on a UTC or GMT second.

Yes, it's because GMT is based on the average solar noon. If you have
an actual sundial, you can observe actual solar noon, but to convert
that to civil time, you need a table of translations that takes
seasonal variation into account. In theory, Greenwich Time would show
noon when the sun is directly overhead, but that would mean that
successive days vary in length; Greenwich Mean Time averages it all
out so you get a consistent 86400-second day.

UTC is defined by the coordination of a bunch of clocks around the
world. There are a few different forms, most of which never go more
than one second away from each other. GMT is usually defined as being
equal to one or other of them, but which one is not entirely
standardized, so if you need subsecond accuracy, don't use GMT at all.
For scheduling events, though, GMT == UTC == TIA == Unix time.

>> But those specifics are
>> part of what I would elide, along with leap seconds and relativity,
>> when explaining a scheduling system.
>
>
> Right, but most people (myself included) only learn about UTC when they
> learn about those complications.  I would say in New York, Eastern Time is
> for most people, EST is for nerds and UTC is for wonks.
>
>> (Let's face it - nobody's going
>> to schedule a meeting to such accuracy that any of it will matter.)
>> Time is a lot messier than most people need to care about.
>
>
> Right.  So let them use the time that their wall clocks are showing.  When a
> New Yorker calls Cupertino, they have three options: Eastern, Pacific and
> UTC.  The first two are a slight inconvenience for one of them and the third
> is a major annoyance for both.

Sure. If you're scheduling a one-off event, that's no problem. But
when you schedule a recurring event, suddenly the first two become
major annoyances and the third becomes much more minor. (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.)

ChrisA