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

[M.-A. Lemburg]

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.

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.

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).

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 16 2010)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2010-07-19: EuroPython 2010, Birmingham, UK                32 days to go

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/