Message75904
| 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 |
|