On Tue, Jun 15, 2010 at 16:01, Cameron Simpson firstname.lastname@example.org wrote:
On 15Jun2010 10:47, Alexander Belopolsky email@example.com wrote: | On Tue, Jun 15, 2010 at 4:07 AM, M.-A. Lemburg firstname.lastname@example.org 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.
Personally, I would be happy to see unix-timestamp and datetime object, and see the time tuples go away.
The tuples are a direct mirror of the unix "struct tm" structures and and should really only be visible in a "posixtime" module of some kind - the datetime objects are their direct equivalents anyway to my mind and should be what are dealt with for human calendar stuff.
However, the unix timestamps should stay (or anything equivalent that measures real world seconds, but since any epoch will do for that purpose and we've got the unix one in use I'd stay with it). They represent an absolute timeframe and let one do direct arithmetic. If I'm not doing calendar things (or only doing them for presentation) then the unix timestamp is usually my preferred time item.
I agree with this sentiment. The UNIX timestamp stuff should stay in time, the time tuple stuff should just go, and datetime should be fleshed out to handle all the stuff that is not a direct wrapping around libc. That way people deal with accurate datetimes as well as well understood concepts with UNIX timestamps and datetime objects. Time tuples are just not accurate enough.
Datetime objects can keep the ability to export and import from time tuples for extensions that need to interface with 'struct tm' code, but otherwise it should be considered a lossy datetime encoding that we do not really support else we are going to constantly be trying to fix the time tuple to be more accurate when it was simply just not well designed.