On Tue, Jun 15, 2010 at 4:07 AM, M.-A. Lemburg <mal@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