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

[Brett Cannon]

On Tue, Jun 15, 2010 at 16:01, Cameron Simpson <cs at zip.com.au> wrote:
> On 15Jun2010 10:47, Alexander Belopolsky <alexander.belopolsky at gmail.com> wrote:
> | 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.
>
> 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.