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

[Brett Cannon]

On Wed, Jun 16, 2010 at 00:56, M.-A. Lemburg <mal at egenix.com> wrote:
> Brett Cannon wrote:
>> 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.
>
> -1.
>
> Please note that the time module provides access to low-level OS
> provided services which the datetime module does not expose.
>
> You cannot seriously expect that an application which happily uses
> the time module (only) for its limited date/time functionality
> to have to be rewritten just to stay compatible with Python.

No, but the work to move people off of time tuples and over to
datetime objects or timestamps can start so that the next stdlib reorg
can drop time tuples without causing major pains.

>
> Note that not all applications are interested in sub-second
> accuracy and a computer without properly configured NTP and good
> internal clock doesn't even provide this accuracy to begin with
> (even if they happily pretend they do by exposing sub-second
> floats).
>
> You might want to do that for Python4 and then add all those
> time module functions using struct_time to the datetime
> module (returning datetime instances), but for Python3, we've
> had the stdlib reorg already.
>
> Renaming time -> posixtime falls into the same category.
>

I don't care as much about the rename as I do about losing time tuples
in the long run.

> The only improvement I could see, would be to move
> calendar.timegm() to the time module, since that's where
> it belongs (keeping an alias in the calendar module, of
> course).

That should definitely happen at some point.