Guido van Rossum wrote: > > > Does this imply leap second hell, or will we > > simply be vague about expectations? > > IMO, leap seconds should be ignored. Time stands still during a leap > second. Consider this a BDFL pronouncement if you wish. :-) > > > I'd also like to see simple access methods for year, > > month, day, hours, minutes, and seconds, > > 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. > 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. 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. > > 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. 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4