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

[Jim Fulton]

Guido van Rossum wrote:
> 
> > > The timetuple() method provides access to all of these
> > > simultaneously.  Isn't that enough?
> >
> > From a minimalist point of view, yet, but from a usability point
> > of view, no.
> >
> > > t.year() could be spelled as
> > > t.timetuple()[0].
> >
> > Yes, but t.year() is a lot more readable.
> 
> When do you ever use this in isolation?  I'd expect in 99% of the
> cases you hand it off to a formatting routine, and guess what --
> strftime() takes a time tuple.
> 
> I worry about the time wasted by calling all of t.year(), t.month(),
> t.day() (etc.) -- given that they do so little, the call overhead is
> probably near 100%.
> 
> I wonder how often this is needed.  The only occurrences of year() in
> the entire Zope source that I found are in various test routines.

These methods and others are used a lot in presentation code, 
which tends to be expressed in DTML or ZPT.

It's not uncommon to select/catagorize things by year or month.

I think most people would find individual date-part methods
a lot more natural than tuples.

> > > I expect that usually you'd request several of
> > > these together anyway, in order to do some fancy formatting, so the
> > > timetuple() approach makes sense.
> >
> > I find the time tuples to be really inconvenient. I *always*
> > have to slice off the parts I don't want, which I find annoying.
> 
> Serious question: what do you tend to do with time values? 

I format them in various ways and I sort them.

> I imagine
> that once we change strftime() to accept an abstract time object,
> you'll never need to call either timetuple() or year() -- strftime()
> will do it for you.

Maybe, if I use strftime, but I don't use strftime all that much.
I can certainly think of even formatting cases (e.g. internationalized
dates) where it's not adequate.
 
> > Hm, now that I mention the extra parts, it seems kind of silly
> > to make implementors of the type come up with weekday, julian day, and
> > a daylight-savings flag. This time format is really biased by
> > the C time library, which is fine for a module that wraps the C library
> > but seems a bit silly for a standard date-time interface.
> 
> That's why /F's pre-PEP allows the implementation to leaves these
> three set to -1.

I missed these. Still, providing -1s seems, uh, vestigial. 
 
> > > > with date parts
> > > > being one based and time parts being zero based.
> > >
> > > I'm not sure what you mean here.
> >
> > Years, months, and days should start from 1.
> > Hours, minutes and seconds should start from 0.
> >
> > One confusion I often have with time tuples is that I know
> > too much about C's time struct, which numbers months from 0
> > and which has years since 1900.
> 
> I guess that confusion is yours alone.  In Python, of course month and
> day start from 1.  Whether years start from 1 is a theological
> question. :-)

I doubt the confusion is mine alone, but I'll take your word for it.

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