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 ever.
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 time ;-)
Still, historic dates are usually referenced by making year 0 == 1 b.c., -1 == 2 b.c., etc.
-- Marc-Andre Lemburg CEO eGenix.com Software GmbH