the Gravity of Python 2

[Ben Finney]

Chris Angelico <rosuav at gmail.com> writes:

> On Thu, Jan 9, 2014 at 1:25 PM, Roy Smith <roy at panix.com> wrote:
> > Because it's easy to get a naive one. You call datetime.utcnow(). If
> > utcnow() returned an aware datetime, that's probably what we would
> > be using. Why didn't utcnow() just return an aware datetime to begin
> > with?
[…]

> But even so, the problem is not "why can't naive timestamps do
> everything I want". The problem is "why is it so hard to get an aware
> timestamp for the current instant". And if you ask *that* question,
> then there's likely to be an answer.

I think Roy's question hits close to a related problem: that the
standard library makes it easy to do a sub-optimal thing, and the
behaviour we all agree is best is not the default.

So, two questions are raised. One is what you've correctly identified:
“Why is it so hard to get an aware timestamp for the current instant?”
The short answer is: because doing that requires a lookup into a
frequently-updated database, which (because it's so frequently updated)
isn't installed along with Python.

The other is: “Why is the default behaviour from the standard library
doing something which I later discover is the wrong thing to do?” The
answer to that is, of course, related to the first one: the right thing
to do isn't currently feasible by default. Not a very satisfactory
answer, but nevertheless a situation we need to deal with today.

> Yes, it *is* simple. It *is* easy. I've been working with pure-UTC
> times (either called time_t, or TIMESTAMP WITH TIME ZONE, or even just
> float) for decades. Like with so many other things, the easiest
> solution is also the best, because you can just work with one stable
> representation and abstraction on the inside, with conversions to/from
> it at the boundaries. It IS that easy.

The difficulty isn't in doing the right thing; the difficulty is in
doscovering that the default behaviour is sub-optimal and then learning
what, exactly *is* the right thing to do.

The right behaviour is easy, but it's not default, and it's not obvious,
and it's a difficult learning process to differentiate the right thing
to do from the several competing easier-to-understand but wrong things.

So, I think you're both correct. The messiness of getting to the right
behaviour is highly obnoxious and technically unnecessary, if only the
bureaucrats and politicians would give up trying to make their mark on
time zones <URL:https://www.youtube.com/watch?v=-5wpm-gesOY>.

With time zones, as with text encodings, there is a single technically
elegant solution (for text: Unicode; for time zones: twelve simple,
static zones that never change) that would work for the whole world if
we could just be free to sweep away all the messy legacy crap and expect
people to stop complicating the matter further.

Until that day comes, though, we as programmers need to learn this messy
arbitrary crap, at least to the point of knowing unambiguously what we
ask the computer to do when it interacts with the messy real world.

-- 
 \           “I prayed for twenty years but received no answer until I |
  `\          prayed with my legs.” —Frederick Douglass, escaped slave |
_o__)                                                                  |
Ben Finney