Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <roy-76D9D0.22351408012014@news.panix.com>
References: <laf00q$10k$1@ger.gmane.org> <mailman.5098.1389053970.18130.python-list@python.org> <78d91$52cbf8e9$541826b9$29485@cache1.tilbu1.nb.home.nl> <4b702$52cc262e$541826b9$22985@cache80.multikabel.net> <4cbf$52cc2e82$541826b9$11761@cache70.multikabel.net> <mailman.5141.1389114029.18130.python-list@python.org> <686$52cd4640$541826b9$21896@cache1.tilbu1.nb.home.nl> <roy-C787B2.09153508012014@news.panix.com> <mailman.5170.1389191449.18130.python-list@python.org> <laknps$umv$1@dont-email.me> <roy-B40DB1.20273008012014@news.panix.com> <mailman.5222.1389232077.18130.python-list@python.org> <roy-956F29.21255508012014@news.panix.com> <mailman.5226.1389237436.18130.python-list@python.org> <roy-76D9D0.22351408012014@news.panix.com>
Date: Thu, 9 Jan 2014 15:03:45 +1100
Subject: Re: the Gravity of Python 2
From: Chris Angelico <rosuav@gmail.com>
Cc: "python-list@python.org" <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.5231.1389240235.18130.python-list@python.org>
Lines: 49
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:63564

On Thu, Jan 9, 2014 at 2:35 PM, Roy Smith <roy@panix.com> wrote:
>> 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.

In Pike:
time();

In PostgreSQL:
SELECT now();

In C:
time(0);

All of these give a value in UTC. The PostgreSQL one gives it to you
as a TIMESTAMP WITH TIME ZONE, the others just as a simple value. I
don't know how they go about figuring out what UTC is, on systems
where the computer clock is in local time (eg Windows), but figure out
they do. It might be expensive but it's done somehow. (Easiest way to
check timezone in C is to look at what time(0)%86400/3600 is - that
should be the hour-of-day in UTC, which as I type is 3. And it is.)

I don't know how to do it in Python because I'm not familiar with the
datetime module. But time.time() returns a value in UTC, which is
verifiable by the above method:

>>> int(time.time())%86400//3600
3

So maybe the key is to use utcfromtimestamp()? I don't know. My
personal preference would be to simply use either int or float
everywhere (float if you need subsecond resolution, int if you're
concerned about massively past or future timestamps), and then
translate to something else for display. Effectively, instead of
working with a datetime object, I would just work with an alternative
representation of instant-in-time which is simply seconds since 1970
(dealing with leap seconds whichever way you like). If the datetime
module causes you pain, don't use it.

Ben, if it's that expensive to get an aware timestamp, why does
time.time() effectively do that? Is it a much more expensive call?

ChrisA