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? I'm not experienced with the module, but a glance at the docs and then a quick try interactively suggests that this might be what you need. 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 might be wrong with my suggestion above, and maybe there isn't even any answer right now, but there certainly could be. 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. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
