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.
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.