[Python-Dev] proposal: add basic time type to the standard library (original) (raw)
Guido van Rossum guido@python.org
Tue, 26 Feb 2002 16:07:48 -0500
- Previous message: [Python-Dev] proposal: add basic time type to the standard library
- Next message: [Python-Dev] proposal: add basic time type to the standard library
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> 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.
> 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.
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.
> > 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. :-)
--Guido van Rossum (home page: http://www.python.org/~guido/)
- Previous message: [Python-Dev] proposal: add basic time type to the standard library
- Next message: [Python-Dev] proposal: add basic time type to the standard library
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]