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 belopolsky
Recipients Neil Muller, andersjm, belopolsky, davidfraser, hodgestar, tebeka, vstinner, werneck
Date 2008-11-24.17:33:05
SpamBayes Score 3.1249238e-05
Marked as misclassified No
Message-id <d38f5330811240933x49bd9163vaf9b56f7ec4259b9@mail.gmail.com>
In-reply-to <1227546823.91.0.931359618478.issue2736@psf.upfronthosting.co.za>
Content
On Mon, Nov 24, 2008 at 12:13 PM, STINNER Victor <report@bugs.python.org> wrote:
..
> Hum, it's maybe not possible to choose between integer and float. Why
> not supporting both? Example:
>  - totimestamp()->int: truncate microseconds
>  - totimestamp(microseconds=True)->float: with microseconds

I would still prefer totimestamp()->(int, int) returning (sec, usec)
tuple.  The important benefit is that such totimestamp() will not
loose information and will support more formats than either of your
->int or ->float variants.  The ->int can then be spelt simply as
totimestamp()[0] and on systems with numpy (which is likely for users
that deal with floats a lot), totimestamp(microseconds=True) is simply
dot([1, 1e-6], totimestamp()). (and s,us = totimestamp(); return s +
us * 1e-6 is not that hard either.)
History
Date User Action Args
2008-11-24 17:33:06belopolskysetrecipients: + belopolsky, tebeka, davidfraser, andersjm, vstinner, werneck, hodgestar, Neil Muller
2008-11-24 17:33:05belopolskylinkissue2736 messages
2008-11-24 17:33:05belopolskycreate