[Python-Dev] proposal: add basic time type to the standard library

Jim Fulton jim@zope.com
Tue, 26 Feb 2002 09:05:44 -0500


"M.-A. Lemburg" wrote:
> 
> "Fred L. Drake, Jr." wrote:
> >
> > Guido van Rossum writes:
> >  > Is comparison the same what Tim mentioned as range searches?  I guess
> >  > a representation like current Zope timestamps or what time.time()
> >  > returns is fine for that -- it is monononous even if not necessarily
> >  > continuous.  I guess a broken-out time tuple is much harder to compare.
> >
> > Yes; as long as ordering is easy to check, we're fine with a long int
> > or some such thing.  The range search is indeed the specific
> > application Jim has in mind.
> 
> Uhm... I think this thread is heading in the wrong direction.
> 
> Fredrik wasn't proposing a solution to Jim's particular
> problem (whatever it was ;-), but instead opting for a solution
> of a large number of Python users out there.

Right. ;)

> While mxDateTime probably works for most of them (and is used by
> pretty much all major database modules out there), some may feel
> that they don't want to rely on external libs for their software
> to run on.

I have no problem relying on external libraries.
 
> I would be willing to make the mxDateTime types subtypes of
> whatever Fredrik comes up with. The only requirement I have is
> that the binary footprint of the types needs to match todays
> layout of mxDateTime types since I need to maintain binary
> compatibility.

The binary footprint of your types, not the standard base class, 
right? I don't see a problem with that,

> The other possibility would be adding a set of new types
> to mxDateTime which focus on low memory requirements rather
> than data roundtrip safety and speed.

What is data roundtrip safety?

I rarely do date-time arithmetic, but I often do date-time-part
extraction. I think that mxDateTime is optimized for arithmetic,
whereas, I'd prefer a type more focussed on extraction efficiency, 
and memory usage,  and that effciently supports time zones. 
This is, of course, no knock on mxDateTime. I also want
fast comparisons, which I presume mxDateTime provides.

Jim

--
Jim Fulton           mailto:jim@zope.com       Python Powered!        
CTO                  (888) 344-4332            http://www.python.org  
Zope Corporation     http://www.zope.com       http://www.zope.org