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, belopolsky, davidfraser, hodgestar, tebeka, vstinner, werneck
Date 2008-11-15.03:17:46
SpamBayes Score 2.4409388e-05
Marked as misclassified No
Message-id <d38f5330811141917n609f8affr634b1b31c6e8c7ff@mail.gmail.com>
In-reply-to <200811150236.34185.victor.stinner@haypocalc.com>
Content
On Fri, Nov 14, 2008 at 8:37 PM, STINNER Victor <report@bugs.python.org> wrote:
> .. but we can create new methods like:
>   datetime.fromepoch(seconds, microseconds=0)    # (int/long, int)

While 1970 is the most popular epoch, I've seen 1900, 2000 and even
2035 (!) being used as well.  Similarly, nanoseconds are used in high
resolution time sources at least as often as microseconds.  This makes
fromepoch() ambiguous and it is really unnecessary because it can be
written as epoch + timedelta(0, seconds, microseconds).

>   datetime.toepoch() -> (seconds, microseconds)  # (int/long, int)

I would much rather have divmod implemented as you suggested in
issue2706 .  Then toepoch is simply

def toepoch(d):
    x, y = divmod(d, timedellta(0, 1))
    return x, y.microseconds
History
Date User Action Args
2008-11-15 03:17:50belopolskysetrecipients: + belopolsky, tebeka, davidfraser, vstinner, werneck, hodgestar, Neil Muller
2008-11-15 03:17:48belopolskylinkissue2736 messages
2008-11-15 03:17:46belopolskycreate