Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset 6671c5039e15 by Alexander Belopolsky in branch 'default':
Issue #2736: Added datetime.timestamp() method.
http://hg.python.org/cpython/rev/6671c5039e15
--
___
Python
Changes by Alexander Belopolsky alexander.belopol...@gmail.com:
--
superseder: Add aware local time support to datetime module -
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2736
___
Roundup Robot devnull@devnull added the comment:
New changeset b55eac85e39c by Alexander Belopolsky in branch 'default':
Issue #2736: Documented how to compute seconds since epoch.
http://hg.python.org/cpython/rev/b55eac85e39c
--
nosy: +python-dev
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
--
components: +Documentation -Library (Lib)
resolution: - fixed
stage: test needed - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
Velko Ivanov viva...@ivanov-nest.com added the comment:
On 04/05/2011 18:22, Alexander Belopolsky wrote:
The datetime module intended to be an island of relative sanity.
... - Tim Peters
Refusing to cooperate with the rest of the world is not sane by my books.
On 04/05/2011 21:06,
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Thu, Apr 7, 2011 at 6:20 AM, Velko Ivanov rep...@bugs.python.org wrote:
..
Converting datetime values to float is easy. Â If your dt is a naive
instance representing UTC time:
  timestamp = (dt - datetime(1970,
Marc-Andre Lemburg m...@egenix.com added the comment:
Just to add another data point to this discussion:
mxDateTime, which in large parts inspired the Python datetime module,
has had a .ticks() method (for local time) and a .gmticks() method
(for UTC) for more than a decade now and so far, I
STINNER Victor victor.stin...@haypocalc.com added the comment:
Marc, could you maybe write a new patching taking care of the DST and
maybe also the timezone? It looks like you have a long experience in
timestamps :-)
--
___
Python tracker
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
STINNER Victor victor.stin...@haypocalc.com added the comment:
Marc, could you maybe write a new patching taking care of the DST and
maybe also the timezone? It looks like you have a long experience in
timestamps
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Tue, Apr 5, 2011 at 4:33 AM, Marc-Andre Lemburg
rep...@bugs.python.org wrote:
..
mxDateTime, which in large parts inspired the Python datetime module,
has had a .ticks() method (for local time) and a .gmticks() method
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
MAL Since most of the datetime module was inspired by mxDateTime,
MAL I wonder why [ticks()/gmticks()] were left out. (msg75411)
The datetime module intended to be an island of relative sanity.
Because the range of dates
Marc-Andre Lemburg m...@egenix.com added the comment:
Alexander Belopolsky wrote:
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Tue, Apr 5, 2011 at 4:33 AM, Marc-Andre Lemburg
rep...@bugs.python.org wrote:
..
mxDateTime, which in large parts inspired the
Marc-Andre Lemburg m...@egenix.com added the comment:
Alexander Belopolsky wrote:
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
MAL Since most of the datetime module was inspired by mxDateTime,
MAL I wonder why [ticks()/gmticks()] were left out. (msg75411)
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Let me state my position on this issue once again. Converting datetime values
to float is easy. If your dt is a naive instance representing UTC time:
timestamp = (dt - datetime(1970, 1, 1)) / timedelta(seconds=1)
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Tue, Apr 5, 2011 at 1:45 PM, Marc-Andre Lemburg
rep...@bugs.python.org wrote:
..
BTW: A timestamp usually refers to the combination of date and
time. The time.time() return value is seconds since the Epoch.
I usually
Jay Taylor outtat...@gmail.com added the comment:
I couldn't agree more with ping's position on this. It is against the spirit
of what Python has set out to be, and the blocking needs to stop.
Any chance we could get a .epoch() function into python 2.7 as well?
--
nosy: +Jay.Taylor
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Mon, Apr 4, 2011 at 5:42 PM, Jay Taylor rep...@bugs.python.org wrote:
..
I couldn't agree more with ping's position on this.
Adding votes to a tracker issue without a working patch will not move
it any further. There
Ka-Ping Yee pyt...@zesty.ca added the comment:
no one has come up with a satisfactory solution
Plenty have proposed a satisfactory solution. No one has come up with a
solution that is satisfactory to *you*, because you have overconstrained the
problem. The reason we still have no
Ka-Ping Yee pyt...@zesty.ca added the comment:
I am extremely disappointed by what has happened here.
We are talking about a very simple method that everybody needs, and that has
been reimplemented over and over again. I have been frustrated countless times
by the lack of a utctotimestamp()
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Thu, Mar 31, 2011 at 2:52 PM, Ka-Ping Yee rep...@bugs.python.org wrote:
..
I am extremely disappointed by what has happened here.
What exactly are you disappointed about? As far as I can tell, the
feature request has
Velko Ivanov viva...@ivanov-nest.com added the comment:
I'm very disappointed by the outcome of this discussion.
You are committing the biggest sin of modern times - instead of promoting the
obtaining and usage of knowledge to solve things, you place restrictions to
force the dumbheads into
R. David Murray rdmur...@bitdance.com added the comment:
Alexander, I agree with Velko in that it isn't obvious to me how the addition
of localtime would answer the desire expressed in this issue. It addresses
Antoine's complaint about aware datetimes, but I don't see that it does
anything
Antoine Pitrou pit...@free.fr added the comment:
Velko: on the other hand, given Victor's research, I don't see float
seconds since an epoch appearing anywhere as a standard.
Well, given that we already have fromtimestamp(), this sounds like a
poor argument against a totimestamp() method (or
Velko Ivanov viva...@ivanov-nest.com added the comment:
on the other hand, given Victor's research, I don't see float seconds since
an epoch appearing anywhere as a standard. Where do you see this being used
as a standard?
Yes, I didn't mean standard as in RFCed and recommended and
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
On Fri, Dec 17, 2010 at 9:18 AM, R. David Murray rep...@bugs.python.org wrote:
R. David Murray rdmur...@bitdance.com added the comment:
Alexander, I agree with Velko in that it isn't obvious to me how the addition
of
Antoine Pitrou pit...@free.fr added the comment:
1. Different application may need different epoch and retained
precision depends on the choice of the epoch.
But then why does fromtimestamp() exist?
And returning a (seconds, microseconds) tuple does retain the precision.
2. The code above
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
On Fri, Dec 17, 2010 at 12:17 PM, Antoine Pitrou rep...@bugs.python.org wrote:
..
1. Different application may need different epoch and retained
precision depends on the choice of the epoch.
But then why does
Antoine Pitrou pit...@free.fr added the comment:
1. Different application may need different epoch and retained
precision depends on the choice of the epoch.
But then why does fromtimestamp() exist?
A better question is why datetime.utcfromtimestamp(s) exists given
that it is
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
On Fri, Dec 17, 2010 at 1:17 PM, Antoine Pitrou rep...@bugs.python.org wrote:
..
A better question is why datetime.utcfromtimestamp(s) exists given
that it is actually longer than equivalent EPOCH + timedelta(0, s)?
???
Changes by Miki Tebeka miki.teb...@gmail.com:
--
nosy: -tebeka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2736
___
___
Python-bugs-list
Antoine Pitrou pit...@free.fr added the comment:
??? EPOCH is not even a constant in the datetime module.
No, and it does not belong there.
And so what was your point exactly?
A higher level library that uses
seconds since epoch for interchange
I don't think the time module can be
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
On Fri, Dec 17, 2010 at 2:35 PM, Antoine Pitrou rep...@bugs.python.org wrote:
..
I don't think the time module can be named higher level, and it
still handles such timestamps.
datetime(1970, 1, 1) + timedelta(seconds=s)
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
--
nosy: -Alexander.Belopolsky
versions: +Python 3.3 -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2736
___
Antoine Pitrou pit...@free.fr added the comment:
Yes, UTC not being a proper acronym in any human language is one
problem,
Ok. Too bad you don't live on the same planet than most of us. I bail
out.
--
___
Python tracker rep...@bugs.python.org
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Fri, Dec 17, 2010 at 3:26 PM, Antoine Pitrou rep...@bugs.python.org wrote:
..
Yes, UTC not being a proper acronym in any human language is one
problem,
Ok. Too bad you don't live on the same planet than most of us.
STINNER Victor victor.stin...@haypocalc.com added the comment:
It looks like it's not possible to choose between float and (int, int) output
type for datetime.totimestamp(). One is more practical (and enough for people
who doesn't need an exact result), and one is needed to keep the same
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
--
superseder: - Add aware local time support to datetime module
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2736
___
Changes by Sebastian Rittau srit...@jroger.in-berlin.de:
--
nosy: -srittau
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2736
___
___
STINNER Victor victor.stin...@haypocalc.com added the comment:
As you explain in your own documentation, the proposed method
is equivalent to ``(time.mktime(self.timetuple()), self.microsecond)``,
so all it does is replacing a less than a one-liner.
a one-liner, but an horrible one liner
Antoine Pitrou pit...@free.fr added the comment:
I agree with Victor that the APIs need improving, even if it involves providing
obvious replacements of obscure one-liners. As an occasional user of datetime
and time modules, I have too often wanted to curse those limited, awkwardly
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
On Fri, May 21, 2010 at 7:26 AM, STINNER Victor rep...@bugs.python.org wrote:
..
... If the tzinfo of the datetime object does not match the
system TZ used by mktime, the result will be quite misleading.
Can you suggest
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
On Fri, May 21, 2010 at 7:37 AM, Antoine Pitrou rep...@bugs.python.org wrote:
..
I agree with Victor that the APIs need improving, even if it involves
providing obvious replacements of obscure one-liners.
While I agree
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
--
assignee: - belopolsky
nosy: -Alexander.Belopolsky
stage: - unit test needed
versions: +Python 3.2 -Python 2.6, Python 3.0
___
Python tracker rep...@bugs.python.org
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
On Fri, May 21, 2010 at 11:20 AM, Alexander Belopolsky
rep...@bugs.python.org wrote:
..
I believe it should be something like this:
from claendar import timegm
s/claendar/calendar/, of course.
--
nosy:
Antoine Pitrou pit...@free.fr added the comment:
The advantage of an obscure one-liner is
that it is obvious what it does, particularly for someone with a
C/UNIX background.
Well, I would argue that the C/Unix legacy in terms of dates and times isn't an
example to follow. Python does not
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
On Fri, May 21, 2010 at 12:20 PM, Antoine Pitrou rep...@bugs.python.org wrote:
..
Well, for example, the datetime module encourages you to use aware datetime
objects (rather than so-called naive objects),
but there isn't
Changes by Skip Montanaro s...@pobox.com:
--
nosy: -skip.montanaro
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2736
___
___
Python-bugs-list
Mark Dickinson dicki...@gmail.com added the comment:
Close issue 1673409 as a duplicate of this one; combining nosy lists.
--
nosy: +catlee, erik.stephens, guettli, jribbens, mark.dickinson, pitrou,
skip.montanaro, srittau, steve.roberts, tim_one, tomster
Changes by Mark Dickinson dicki...@gmail.com:
--
nosy: +amaury.forgeotdarc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2736
___
___
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
Victor,
As you explain in your own documentation, the proposed method is equivalent to
``(time.mktime(self.timetuple()), self.microsecond)``, so all it does is
replacing a less than a one-liner. Moreover, I am not sure
Changes by STINNER Victor victor.stin...@haypocalc.com:
Removed file: http://bugs.python.org/file12013/datetime_totimestamp.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2736
___
STINNER Victor victor.stin...@haypocalc.com 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
STINNER Victor victor.stin...@haypocalc.com 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
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 (originated at
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
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
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)
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
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
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
-
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 prefer
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 information
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 (.doc), ASF
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 tz
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(1970,
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; directly
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
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,
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:
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 1900,
STINNER Victor [EMAIL PROTECTED] added the comment:
See also issue1673409
--
nosy: +haypo
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2736
___
___
Miki Tebeka [EMAIL PROTECTED] added the comment:
I think the name is not good, should be toepoch or something like that.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2736
__
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]
http://bugs.python.org/issue2736
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:
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]
http://bugs.python.org/issue2736
Changes by David Fraser [EMAIL PROTECTED]:
--
nosy: +davidfraser
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2736
__
___
Python-bugs-list mailing list
Unsubscribe:
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
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) == dt
78 matches
Mail list logo
