[Python-Dev] proposal: add basic time type to the standard library
Tue, 26 Feb 2002 22:26:47 +0100
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().
> > 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.
FWIW, mxDateTime exposes these values as attributes -- there
is no call overhead.
> 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.
I actually use the attributes quite a bit in my stuff
and hardly ever use .strftime(). The mxDateTime is different
though, e.g. I sometimes get questions about how to make
strftime() output fractions of a seconds (doesn't work, because
strftime() doesn't support it).
> > > 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 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.
Depends on the application space. Database applications
will call .timetuple() very often and use strftime() hardly
> > > > 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. :-)
It's not really a question: the year 0 simply does not exist
in reality ! (Christians didn't have a 0 available at the
Still, historic dates are usually referenced by making year 0 ==
1 b.c., -1 == 2 b.c., etc.
CEO eGenix.com Software GmbH
Company & Consulting: http://www.egenix.com/
Python Software: http://www.egenix.com/files/python/