In article <mailman.5226.1389237436.18130.python-l...@python.org>, Chris Angelico <ros...@gmail.com> wrote:
> On Thu, Jan 9, 2014 at 1:25 PM, Roy Smith <r...@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. -- https://mail.python.org/mailman/listinfo/python-list
