the Gravity of Python 2

[Roy Smith]

In article <mailman.5226.1389237436.18130.python-list at python.org>,
 Chris Angelico <rosuav at gmail.com> wrote:

> 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?
> >
> > Conversely, it's a pain in the butt to get an aware one.  As far as I
> > can tell, you have to do something like:
> >
> > utcnow().replace(tzinfo=pytz.utc)
> >
> > which is not only ugly, but requires installing a third-party module
> > (pytz) to get the UTC timezone definition.
> 
> What's datetime.today() give you?

It almost gives you an aware UTC datetime.  Other than it being naive, 
and being in local time, that is :-)

> 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.

You asked,  Why not simply use a UTC datetime instead
of a naive one?"  My answer is that it's not simple at all.

> 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.

Please show me the simple code to obtain an aware UTC datetime 
representing the current time.