[Python-ideas] Rename time module to "posixtime"

[Alexander Belopolsky]

On Tue, Jun 15, 2010 at 4:07 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> Alexander Belopolsky wrote:
>> One of the common complains about working with time values in Python,
>> is that it some functionality is available in time module, some in
>> datetime module and some in both.
..
> I'm not sure I understand the point in renaming the module.

I've reread my post and have to admit that I did not explain this
point clearly.  There are currently three different ways to represent
a point in time: datetime object, unix timestamp, and a 9-element time
tuple.  While the datetime module has its share of criticism, its
interfaces are more user friendly and more "pythonic" than C inspired
time module interfaces.

For example,

>>> print(datetime.now())

is self-explainatory but

>>> time.time()
1276609479.559051

requires a lot of explaining even to people with C/POSIX background.
For the later, the immediate questions would be why the output is a
float and what is the precision of the result.  For people without C
background, time module interfaces are cryptic and arbitrary.  Why
time() produces a float while localtime() produces a tuple?  Why
asctime takes tuple while ctime takes float?

Conversions between timestamp/timetuple and datetime are quite awkward
as well. We have datetime.timetuple(), but no fromtimetuple() (you
have to write cryptic datetime(*tt[:6]).  With timestamps, it is the
opposite.  We have a full compliment of
fromtimestamp/utcfromtimestamp, but no functions to go in the opposite
direction.

Finally, we have a 3-way name conflict: time is a module, a function and a type.

I believe most of applications are better off using datetime module
exclusively.  The time module should be used for interoperability with
POSIX interfaces, but not for general date/time manipulations.
Renaming the module will
make its name match its purpose better.

> Note that the time module works based on Unix ticks (seconds
> since the Unix Epoch), while the datetime module works based
> on its own set of types.
>
I certainly know that.  What some people don't understand, though is
that translation between Unix ticks (or more accurately POSIX time_t
value) and broken down UTC time is just an arithmetic operation.  The
formula is convoluted, but it is just a formula independent of any
system databases.  There is no good reason for a python application to
keep time values as POSIX timestamps rather than datetime objects.
The correspondence between the two is one to one, the ordering is the
same and arithmetics is cleaner with datetime because it is explicit
about (decimal) precision.

> As such, the two are different implementations for managing
> date/time. Mixing them won't make things easier to understand.
> The time module is very close to the C lib API, while the datetime
> module focuses more on date/time storage in a more accessible.
>

I am not proposing mixing them.  To the contrary, I want to make it
clearer that users should not mix them: use posixtime module if you
need to interoperate with posix interfaces and datetime for everything
else.

> I agree on one point, though: the shared C APIs for getting the
> current time would be better put into a separate C extension
> which both can then load without creating circular references,
> e.g. _getcurrenttime.c.

What I would like to do is to expose POSIX gettimeofday interface as
both C API and python function returning (seconds, microseconds)
tuple.  In my view, C implementation should go to _posixtimemodule.c
and posixtime.py should have

def gettimeofday():
     q, r = divmod(datetime.utcnow() - datetime(1970,1,1), timedelta(seconds=1))
     return q, r.microseconds