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

2002年2月26日 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