[issue1673409] datetime module missing some important methods

Mark Dickinson added the comment: > Aggrrr! How did that slip in? :-) Blame Antoine. :) (See issue 5788 and revision 76529.) > Shouldn't td.total_seconds() return Decimal? Maybe in py4k ... Yes, that would have been nice. I'm not sure that the Decimal type is well-established enough yet

[issue1673409] datetime module missing some important methods

Alexander Belopolsky added the comment: On Wed, Apr 21, 2010 at 2:03 PM, Mark Dickinson wrote: .. > (BTW, as well as the newly introduced division methods, td.tosecs already > exists, except that it's spelt td.total_seconds.) Aggrrr! How did that slip in? :-) 8639913600.0 Shouldn't td.

[issue1673409] datetime module missing some important methods

Mark Dickinson added the comment: Closing this as a duplicate of issue 2736, as suggested. I'll combine the nosy lists. (BTW, as well as the newly introduced division methods, td.tosecs already exists, except that it's spelt td.total_seconds.) -- resolution: -> duplicate status: op

[issue1673409] datetime module missing some important methods

Alexander Belopolsky added the comment: With issue2706 accepted, I think this issue can now be rejected because proposed td.tosecs() can now be spelled simply as td/timedelta(seconds=1). The other RFE for a totimestamp() method is a duplicate of issue2736. -- nosy: +Alexander.Belopols

[issue1673409] datetime module missing some important methods

Changes by Marc-Andre Lemburg : -- nosy: -lemburg ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue1673409] datetime module missing some important methods

Changes by Brett Cannon : -- nosy: -brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue1673409] datetime module missing some important methods

Jon Ribbens added the comment: > A timedelta.toseconds method (or equivalent) makes no sense. > The number of seconds in a day is not fixed (due to leap seconds) and > relying on such a method would introduce subtle bugs. You are misunderstanding what timedelta is. It is a fixed-length period o

[issue1673409] datetime module missing some important methods

Antoine Pitrou added the comment: What you say is "with 99500 days or more, the microsecond error is bigger than 90%". It means that with epoch starting at 1970, you can still return timestamps with a 1-2 microsecond accuracy for the year 2242. Additional precision would be overkill. _

[issue1673409] datetime module missing some important methods

STINNER Victor added the comment: > (...) totimestamp() (...) return value should be similar > to that of time.time(), i.e. a float float is a source of many problems (rounding problems), especially for huge values: float is unable to store correctly microseconds for big values: see msg75426.

[issue1673409] datetime module missing some important methods

Sebastian Rittau added the comment: Leap second handling is usually configurable. Default on Debian Linux (but similar on RHEL and SuSE): >>> int(date(1994,1,1).strftime("%s")) - int(date(1993,1,1).strftime("%s")) 31536000 After doing "cp /usr/share/zoneinfo/right/Europe/Berlin /etc/localtime"

[issue1673409] datetime module missing some important methods

Antoine Pitrou added the comment: I also think totimestamp() on datetime objects would be useful, I've missed it myself a couple of times. The return value should be similar to that of time.time(), i.e. a float. -- nosy: +pitrou ___ Python tracker <

[issue1673409] datetime module missing some important methods

STINNER Victor added the comment: I removed my ".toseconds() method" patch because I prefer division. See issue #2706 for divison, divmod, etc. ___ Python tracker ___

[issue1673409] datetime module missing some important methods

Changes by STINNER Victor : Removed file: http://bugs.python.org/file11919/timedelta_toseconds_float.patch ___ Python tracker ___ ___ Python

[issue1673409] datetime module missing some important methods

STINNER Victor added the comment: > The number of seconds in a day is not fixed (due to leap seconds) POSIX timestamp doesn't count leap seconds. It looks like the datetime module is not aware of the leap seconds: >>> print datetime.datetime(2006, 1, 1) - datetime.datetime(2005, 12, 31) 1 da

[issue1673409] datetime module missing some important methods

Sebastian Rittau added the comment: A timedelta.toseconds method (or equivalent) makes no sense. The number of seconds in a day is not fixed (due to leap seconds) and relying on such a method would introduce subtle bugs. The only way to find out the number of seconds in a range of dates is if yo

[issue1673409] datetime module missing some important methods

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: I was going to say the same as Amaury: timedelta / timedelta is dimensionless (time units cancel each other in division) and the advantage of this notation is that you get a way to express timedelta.toxxx for all units accepted in constr

[issue1673409] datetime module missing some important methods

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: > timedelta / timedelta -> seconds? days? nanoseconds? The quotient of two timedelta is a dimensionless number with no unit: timedelta(hours=1) / timedelta(minutes=5) == 12.0 This seems well defined, where is the ambiguity? ---

[issue1673409] datetime module missing some important methods

STINNER Victor <[EMAIL PROTECTED]> added the comment: >>> (t - epoch) // timedelta(seconds=1) I don't like this syntax, because I can't guess the result unit: datetime - datetime -> timedelta but: timedelta / timedelta -> seconds? days? nanoseconds? If you example, you used timedelta(second

[issue1673409] datetime module missing some important methods

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: Chris> I keep needing to know the number of seconds that a timedelta Chris> represents. I propose an alternative approach that I believe will neatly solve fractional vs. whole seconds and multitude of conceivable toxxx methods: Let's

[issue1673409] datetime module missing some important methods

STINNER Victor <[EMAIL PROTECTED]> added the comment: See also issue2736 ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list maili

[issue1673409] datetime module missing some important methods

STINNER Victor <[EMAIL PROTECTED]> added the comment: New patch based on catlee's patch: add toseconds() method to timedelta but use the float type to keep the microseconds. The error between the exact value and IEEE754 value is small: the error is smaller than one second even with 9 d

[issue1673409] datetime module missing some important methods

STINNER Victor <[EMAIL PROTECTED]> added the comment: I wrote this function is my program: def timedelta2seconds(delta): """ Convert a datetime.timedelta() objet to a number of second (floatting point number). >>> timedelta2seconds(timedelta(seconds=2, microseconds=4)) 2

[issue1673409] datetime module missing some important methods

Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment: You can have all this by using the time module's functions. It is true that these don't work for all dates, but they are still useful to have. FWIW: mxDateTime has always had methods to convert the date/time values to ticks and back agai

[issue1673409] datetime module missing some important methods

Skip Montanaro <[EMAIL PROTECTED]> added the comment: Unassigning. Haven't heard from Tim in quite awhile and he's made no input on this issue. Also bump to 2.7. -- assignee: tim_one -> versions: +Python 2.7 -Python 2.6 ___ Python tracker <[EMAIL

[issue1673409] datetime module missing some important methods

Steve Roberts <[EMAIL PROTECTED]> added the comment: I would like to add a use case, generating random dates. Especially generating random dates/times according to different probability distributions and within ranges. It would be nicest if operations could be done directly with datetime, date, t

[issue1673409] datetime module missing some important methods

Erik Stephens <[EMAIL PROTECTED]> added the comment: I'm not sure this is still being considered, so I just wanted to add my opinion. This seems like such a simple request being made overly complicated. We just want seconds since epoch since that is used in many other functions and libraries (i

[issue1673409] datetime module missing some important methods

Chris AtLee added the comment: 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 to

[issue1673409] datetime module missing some important methods

Skip Montanaro added the comment: Chris> I keep needing to know the number of seconds that a timedelta Chris> represents, so I implemented the following patch. I can sympathize, but if we accept this patch, for symmetry reasons shouldn't we also add .todays, .tomicroseconds and maybe even .t

[issue1673409] datetime module missing some important methods

Chris AtLee added the comment: I keep needing to know the number of seconds that a timedelta represents, so I implemented the following patch. This returns only the integer portion, but could be modified to return a floating point value. -- nosy: +catlee Added file: http://bugs.python.o

[issue1673409] datetime module missing some important methods

Jon Ribbens added the comment: Skip has already provided what amounts to a patch. It just needs to be decided whether to (a) not include it, (b) include it with the floating point part, or (c) include it without the floating point part. I couldn't comment as to how many people need it. I can say

[issue1673409] datetime module missing some important methods

Brett Cannon added the comment: This is not going to go anywhere without someone offering a patch to implement this. Plus I suspect this has a much greater use in the C API than in the Python API for datetime. -- nosy: +brett.cannon _ Tracker <[EMAIL

[issue1673409] datetime module missing some important methods

Jon Ribbens added the comment: Well, I still think that a convert-to-time_t function is essential, and I don't buy any of the counter-arguments so far. The only argument I can see is "should it return float or integer?" - floats are inaccurate and integers can't represent partial seconds. __

[issue1673409] datetime module missing some important methods

Skip Montanaro added the comment: One other thing worth noting is that %s is not universally available. Solaris, for example, lacks it in its strftime() implementation. (It has a bazillion other non-standard format strings but not %s.) Skip _ Tracker <[EMAI

[issue1673409] datetime module missing some important methods

Skip Montanaro added the comment: >> No fractions of a second... Jon> If we're expecting floating-point, then everything you said earlier Jon> about the limitations of ints was a bit redundant ;-) Yes, sorry. I responded to the mail without going back and reviewing the entire thread.

[issue1673409] datetime module missing some important methods

Jon Ribbens added the comment: > No fractions of a second... If we're expecting floating-point, then everything you said earlier about the limitations of ints was a bit redundant ;-) _ Tracker <[EMAIL PROTECTED]>

[issue1673409] datetime module missing some important methods

Skip Montanaro added the comment: Tom> unless I'm missing something important this will do the trick quite Tom> nicely: from datetime import datetime datetime(2007, 12, 24, 20, 0).strftime("%s") Tom> '1198522800' Tom> For most imaginable use cases, where an epo

[issue1673409] datetime module missing some important methods

Tom Lazar added the comment: unless I'm missing something important this will do the trick quite nicely: >>> from datetime import datetime >>> datetime(2007, 12, 24, 20, 0).strftime("%s") '1198522800' For most imaginable use cases, where an epoch style time stamp is required this

[issue1673409] datetime module missing some important methods

Skip Montanaro added the comment: Jon> Almost everything you just said about time_t is wrong. time_t is Jon> signed, and always has been (otherwise the 'end of time' for 32-bit Jon> time_t would be 2106, not 2038). Also, time_t does not end at 2038 Jon> because nothing says it must be

[issue1673409] datetime module missing some important methods

Jon Ribbens added the comment: Almost everything you just said about time_t is wrong. time_t is signed, and always has been (otherwise the 'end of time' for 32-bit time_t would be 2106, not 2038). Also, time_t does not end at 2038 because nothing says it must be 32 bits. Also, Python has 'long in

[issue1673409] datetime module missing some important methods

Skip Montanaro added the comment: There is no datetime.totimestamp because the range of time represented by a datetime object far exceeds the range of a normal int-based Unix timestamp (roughly 1970-2038). Datetime objects before the start of the Unix epoch would be represented by negative numbe