This issue tracker has been migrated to GitHub ,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
| Author | catlee |
|---|---|
| Recipients | brett.cannon, catlee, guettli, jribbens, skip.montanaro, tim.peters, tomster |
| Date | 2007年12月01日.21:01:02 |
| SpamBayes Score | 0.0037640047 |
| Marked as misclassified | No |
| Message-id | <1196542863.26.0.718807083715.issue1673409@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
timedelta.todays() could be useful in general I suppose. I think timedelta.toweeks() could be omitted since it's simple division by an easy to recognize constant...also the timedelta docs say that it stores data in terms of microseconds, seconds, and days. OTOH tohours(), tominutes(), etc. (all the units that the constructor uses) could be useful in some cases. My feeling is that adding a method for each time unit bloats the API too much. Personally I've only ever wanted to know the number of seconds a timedelta represents. It seems like seconds are a good base unit to support since it allows easier interoperability with other python types and external data. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2007年12月01日 21:01:03 | catlee | set | spambayes_score: 0.003764 -> 0.0037640047 recipients: + catlee, tim.peters, skip.montanaro, brett.cannon, jribbens, guettli, tomster |
| 2007年12月01日 21:01:03 | catlee | set | spambayes_score: 0.003764 -> 0.003764 messageid: <1196542863.26.0.718807083715.issue1673409@psf.upfronthosting.co.za> |
| 2007年12月01日 21:01:03 | catlee | link | issue1673409 messages |
| 2007年12月01日 21:01:02 | catlee | create | |