[issue2736] datetime needs and "epoch" method

Changes by STINNER Victor : Removed file: http://bugs.python.org/file12123/timestamp.py ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue2736] datetime needs and "epoch" method

Changes by STINNER Victor : Removed file: http://bugs.python.org/file12014/datetime_totimestamp-2.patch ___ Python tracker ___ ___ Python-bugs-

[issue2736] datetime needs and "epoch" method

Changes by STINNER Victor : Removed file: http://bugs.python.org/file12013/datetime_totimestamp.patch ___ Python tracker ___ ___ Python-bugs-li

[issue2736] datetime needs and "epoch" method

STINNER Victor added the comment: About mktime() -> -1: see the Issue1726687 (I found the fix in this issue). Next job will be to patch datetime.(utc)fromtimestamp() to support (int, int). I tried to write such patch but it's not easy because fromtimestamp() will support: int, long, float, (

[issue2736] datetime needs and "epoch" method

STINNER Victor added the comment: belopolsky will be happy to see this new version of my patch: - datetime.totimestamp() => (seconds, microseconds): two integers - datetime.totimestamp() implement don't use Python time.mktime() but directly the C version of mktime() because time.mktime() crea

[issue2736] datetime needs and "epoch" method

David Fraser <[EMAIL PROTECTED]> added the comment: - "STINNER Victor" <[EMAIL PROTECTED]> wrote: > STINNER Victor <[EMAIL PROTECTED]> added the comment: > > Timedelta formats: > > (a) Win64: 64 bits unsigned integer, number of 1/10 microsecond > - file format: Microsoft Word document (.d

[issue2736] datetime needs and "epoch" method

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: On Mon, Nov 24, 2008 at 12:34 PM, STINNER Victor <[EMAIL PROTECTED]> wrote: .. >> I would still prefer totimestamp()->(int, int) returning (sec, usec) >> tuple. The important benefit is that such totimestamp() will not >> loose informat

[issue2736] datetime needs and "epoch" method

STINNER Victor <[EMAIL PROTECTED]> added the comment: > > 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 pref

[issue2736] datetime needs and "epoch" method

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: On Mon, Nov 24, 2008 at 12:13 PM, STINNER Victor <[EMAIL PROTECTED]> wrote: .. > Hum, it's maybe not possible to choose between integer and float. Why > not supporting both? Example: > - totimestamp()->int: truncate microseconds > - to

[issue2736] datetime needs and "epoch" method

STINNER Victor <[EMAIL PROTECTED]> added the comment: Ooops, timestamp (c) is the *Mac* timestamp: seconds since the 1st january 1904. > what is your conclusion? Hum, it's maybe not possible to choose between integer and float. Why not supporting both? Example: - totimestamp()->int: truncate

[issue2736] datetime needs and "epoch" method

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: That's an impressive summary, but what is your conclusion? I don't see any format that will benefit from a subsecond timedelta.totimestamp(). Your examples have either multisecond or submicrosecond resolution. On Mon, Nov 24, 2008 at

[issue2736] datetime needs and "epoch" method

STINNER Victor <[EMAIL PROTECTED]> added the comment: Timedelta formats: (a) Win64: 64 bits unsigned integer, number of 1/10 microsecond - file format: Microsoft Word document (.doc), ASF video (.asf) (b) 64 bits float, number of seconds - file format: AMF metadata used in Flash video (.flv)

[issue2736] datetime needs and "epoch" method

STINNER Victor <[EMAIL PROTECTED]> added the comment: About the timestamp, there are many formats: (a) UNIX: 32 bits signed integer, number of seconds since the 1st january 1970. - file format: gzip header, Portable Executable (PE, Windows), compiled python script header (.pyc/.pyo) - file

[issue2736] datetime needs and "epoch" method

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: On Mon, Nov 24, 2008 at 9:04 AM, David Fraser <[EMAIL PROTECTED]> wrote: ... > The point for me is that having to interact with Microsoft systems that > require times means that the conversions have to be done. I did not see the "epoch

[issue2736] datetime needs and "epoch" method

David Fraser <[EMAIL PROTECTED]> added the comment: - "Alexander Belopolsky" <[EMAIL PROTECTED]> wrote: > Alexander Belopolsky <[EMAIL PROTECTED]> added the > comment: > > I would like to voice my opposition the totimestamp method. > > Representing time as a float is a really bad idea (orig

[issue2736] datetime needs and "epoch" method

Anders J. Munch <[EMAIL PROTECTED]> added the comment: Any thoughts to time zone/DST handling for naive datetime objects? E.g. suppose the datetime object was created by .utcnow or .utcfromtimestamp. For aware datetime objects, I think the time.mktime(dt.timetuple()) approach doesn't work; the t

[issue2736] datetime needs and "epoch" method

STINNER Victor <[EMAIL PROTECTED]> added the comment: Le Saturday 15 November 2008 04:17:50 Alexander Belopolsky, vous avez écrit : > it is really unnecessary because it can be > written as epoch + timedelta(0, seconds, microseconds). I tried yesterday and it doesn't work! datetime.datetime(197

[issue2736] datetime needs and "epoch" method

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: On Fri, Nov 14, 2008 at 8:37 PM, STINNER Victor <[EMAIL PROTECTED]> 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 190

[issue2736] datetime needs and "epoch" method

STINNER Victor <[EMAIL PROTECTED]> added the comment: Le Saturday 15 November 2008 02:15:30 Alexander Belopolsky, vous avez écrit : > I don't think changing fromtimestamp behavior is an option. It's too late to break the API (Python3 is in RC stage ;-)), but we can create new methods like: d

[issue2736] datetime needs and "epoch" method

Alexander Belopolsky <[EMAIL PROTECTED]> 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,

[issue2736] datetime needs and "epoch" method

STINNER Victor <[EMAIL PROTECTED]> added the comment: Here is a merged patch of the three patches. Except the C implementation of datetime_totimestamp() (written by me), all code is written by hodgestar. Added file: http://bugs.python.org/file12014/datetime_totimestamp-2.patch ___

[issue2736] datetime needs and "epoch" method

STINNER Victor <[EMAIL PROTECTED]> added the comment: I like the method, but I have some comments about the new method: - datetime_totimestamp() is not well indented - "PyObject *time" should be defined at the before the first instruction - why not using "if (time == NULL) return NULL;" direc

[issue2736] datetime needs and "epoch" method

STINNER Victor <[EMAIL PROTECTED]> added the comment: See also issue1673409 -- nosy: +haypo ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue2736] datetime needs and "epoch" method

Neil Muller <[EMAIL PROTECTED]> added the comment: datetime has fromtimestamp already, so using totimestamp keeps naming consistency (see toordinal and fromordinal). -- nosy: +Neil Muller __ Tracker <[EMAIL PROTECTED]> _

[issue2736] datetime needs and "epoch" method

Miki Tebeka <[EMAIL PROTECTED]> added the comment: I think the name is not good, should be "toepoch" or something like that. __ Tracker <[EMAIL PROTECTED]> __ __

[issue2736] datetime needs and "epoch" method

Changes by David Fraser <[EMAIL PROTECTED]>: -- nosy: +davidfraser __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscri

[issue2736] datetime needs and "epoch" method

Simon Cross <[EMAIL PROTECTED]> added the comment: Patch adding documentation for datetime.totimestamp(...). Added file: http://bugs.python.org/file10256/add-datetime-totimestamp-method-docs.diff __ Tracker <[EMAIL PROTECTED]>

[issue2736] datetime needs and "epoch" method

Simon Cross <[EMAIL PROTECTED]> added the comment: Attached a patch which adds a .totimetuple(...) method to datetime.datetime and tests for it. The intention is that the dt.totimetuple(...) method is equivalent to: mktime(dt.timetuple()) + (dt.microsecond / 100.0) -- keywords: +pat

[issue2736] datetime needs and "epoch" method

Pedro Werneck <[EMAIL PROTECTED]> added the comment: That's expected as mktime is just a thin wrapper over libc mktime() and it does not expect microseconds. Changing time.mktime doesn't seems an option, so the best alternative is to implement a method in datetime type. Is there a real demand for

[issue2736] datetime needs and "epoch" method

New submission from Miki Tebeka <[EMAIL PROTECTED]>: If you try to convert datetime objects to seconds since epoch and back it will not work since the microseconds get lost: >>> dt = datetime(2008, 5, 1, 13, 35, 41, 56) >>> seconds = mktime(dt.timetuple()) >>> datetime.fromtimestamp(seconds)