Message76324
| Author |
davidfraser |
| Recipients |
Neil Muller, andersjm, belopolsky, davidfraser, hodgestar, tebeka, vstinner, werneck |
| Date |
2008年11月24日.14:04:46 |
| SpamBayes Score |
7.6127953e-06 |
| Marked as misclassified |
No |
| Message-id |
<667436787.107671227518475401.JavaMail.root@klofta.sjsoft.com> |
| In-reply-to |
<1226711729.86.0.312684878446.issue2736@psf.upfronthosting.co.za> |
| Content |
----- "Alexander Belopolsky" <report@bugs.python.org> wrote:
> Alexander Belopolsky <belopolsky@users.sourceforge.net> added the
> comment:
>
> I would like to voice my opposition the totimestamp method.
>
> Representing time as a float is a really bad idea (originated at
> Microsoft as I have heard). In addition to the usual numeric problems
> when dealing with the floating point, the resolution of the floating
> point timestamp varies from year to year making it impossible to
> represent high resolution historical data.
>
> In my opinion both time.time() returning float and
> datetime.fromtimestamp() taking a float are both design mistakes and
> adding totimestamp that produces a float will further promote a bad
> practice.
The point for me is that having to interact with Microsoft systems that require times means that the conversions have to be done. Is it better to have everybody re-implement this, with their own bugs, or to have a standard implementation? I think it's clearly better to have it as a method on the object. Of course, we should put docs in describing the pitfalls of this approach... |
|