[issue2736] datetime needs an "epoch" method

Changes by Alexander Belopolsky : -- superseder: Add aware local time support to datetime module -> ___ Python tracker ___ ___ Python-

[issue2736] datetime needs an "epoch" method

Roundup Robot 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 tracker

[issue2736] datetime needs an "epoch" method

Changes by Alexander Belopolsky : -- components: +Documentation -Library (Lib) resolution: -> fixed stage: test needed -> committed/rejected status: open -> closed ___ Python tracker ___

[issue2736] datetime needs an "epoch" method

Roundup Robot 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 ___ Python tracker

[issue2736] datetime needs an "epoch" method

Alexander Belopolsky added the comment: On Thu, Apr 7, 2011 at 6:20 AM, Velko Ivanov wrote: .. >> 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) >> >> If your dt

[issue2736] datetime needs an "epoch" method

Velko Ivanov 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 Belopols

[issue2736] datetime needs an "epoch" method

Alexander Belopolsky added the comment: On Tue, Apr 5, 2011 at 1:45 PM, Marc-Andre Lemburg 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 call those values "ticks" (not sure whether it's

[issue2736] datetime needs an "epoch" method

Alexander Belopolsky 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) If your dt is an aware instance:

[issue2736] datetime needs an "epoch" method

Marc-Andre Lemburg added the comment: Alexander Belopolsky wrote: > > Alexander Belopolsky 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

[issue2736] datetime needs an "epoch" method

Marc-Andre Lemburg added the comment: Alexander Belopolsky wrote: > > Alexander Belopolsky added the comment: > > On Tue, Apr 5, 2011 at 4:33 AM, Marc-Andre Lemburg > wrote: > .. >> mxDateTime, which in large parts inspired the Python datetime module, >> has had a .ticks() method (for local

[issue2736] datetime needs an "epoch" method

Alexander Belopolsky 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 "timestamps" can represent v

[issue2736] datetime needs an "epoch" method

Alexander Belopolsky added the comment: On Tue, Apr 5, 2011 at 4:33 AM, Marc-Andre Lemburg wrote: .. > 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 Yes, mxDateTi

[issue2736] datetime needs an "epoch" method

Marc-Andre Lemburg added the comment: STINNER Victor wrote: > > STINNER Victor 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 :-) Sorry, but no. I'm not really a

[issue2736] datetime needs an "epoch" method

STINNER Victor 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

[issue2736] datetime needs an "epoch" method

Marc-Andre Lemburg 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 haven't seen a sin

[issue2736] datetime needs an "epoch" method

Alexander Belopolsky added the comment: On Mon, Apr 4, 2011 at 5:42 PM, Jay Taylor 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 are several committers besides me in the nosy list in

[issue2736] datetime needs an "epoch" method

Jay Taylor 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

[issue2736] datetime needs an "epoch" method

Ka-Ping Yee 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 utctotimestamp() after a

[issue2736] datetime needs an "epoch" method

Alexander Belopolsky added the comment: On Thu, Mar 31, 2011 at 2:52 PM, Ka-Ping Yee 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 not been rejected, just no one has come up with a sa

[issue2736] datetime needs an "epoch" method

Ka-Ping Yee 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() method. I have

[issue2736] datetime needs an "epoch" method

STINNER Victor 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 resolution than the datetime obje

[issue2736] datetime needs an "epoch" method

Alexander Belopolsky added the comment: On Fri, Dec 17, 2010 at 3:26 PM, Antoine Pitrou 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. I bail > out. Sorry that my attempt at humor ha

[issue2736] datetime needs an "epoch" method

Antoine Pitrou 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

[issue2736] datetime needs an "epoch" method

Changes by Alexander Belopolsky : -- nosy: -Alexander.Belopolsky versions: +Python 3.3 -Python 3.2 ___ Python tracker ___ ___ Python-b

[issue2736] datetime needs an "epoch" method

Alexander Belopolsky added the comment: On Fri, Dec 17, 2010 at 2:35 PM, Antoine Pitrou 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) >> >> is obvious, self-contained,  short and

[issue2736] datetime needs an "epoch" method

Antoine Pitrou 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 named "hig

[issue2736] datetime needs an "epoch" method

Changes by Miki Tebeka : -- nosy: -tebeka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.or

[issue2736] datetime needs an "epoch" method

Alexander Belopolsky added the comment: On Fri, Dec 17, 2010 at 1:17 PM, Antoine Pitrou wrote: .. >> A better question is why datetime.utcfromtimestamp(s) exists given >> that it is actually longer than equivalent EPOCH + timedelta(0, s)? > > ??? EPOCH is not even a constant in the datetime mod

[issue2736] datetime needs an "epoch" method

Antoine Pitrou 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 actually

[issue2736] datetime needs an "epoch" method

Alexander Belopolsky added the comment: On Fri, Dec 17, 2010 at 12:17 PM, Antoine Pitrou wrote: .. >> 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.u

[issue2736] datetime needs an "epoch" method

Antoine Pitrou 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 works only on

[issue2736] datetime needs an "epoch" method

Alexander Belopolsky added the comment: On Fri, Dec 17, 2010 at 9:18 AM, R. David Murray wrote: > > R. David Murray 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. Conversio

[issue2736] datetime needs an "epoch" method

Velko Ivanov 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 dominant, sorry if it soun

[issue2736] datetime needs an "epoch" method

Antoine Pitrou 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 whatever it g

[issue2736] datetime needs an "epoch" method

R. David Murray 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 for the "conversion to

[issue2736] datetime needs an "epoch" method

Velko Ivanov 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 not doing mistakes. The b

[issue2736] datetime needs an "epoch" method

Changes by Alexander Belopolsky : -- superseder: -> Add aware local time support to datetime module ___ Python tracker ___ ___ Python-

[issue2736] datetime needs an "epoch" method

Changes by Sebastian Rittau : -- nosy: -srittau ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue2736] datetime needs an "epoch" method

Alexander Belopolsky added the comment: On Fri, May 21, 2010 at 12:20 PM, Antoine Pitrou wrote: .. > Well, for example, the datetime module encourages you to use "aware" datetime > objects (rather than so-called "naive" objects), > but there isn't a single facility to do so. You must reinvent

[issue2736] datetime needs an "epoch" method

Antoine Pitrou 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 force you to u

[issue2736] datetime needs an "epoch" method

Alexander Belopolsky added the comment: On Fri, May 21, 2010 at 11:20 AM, Alexander Belopolsky wrote: .. > I believe it should be something like this: > > from claendar import timegm s/claendar/calendar/, of course. -- nosy: +Alexander.Belopolsky _

[issue2736] datetime needs an "epoch" method

Changes by Alexander Belopolsky : -- assignee: -> belopolsky nosy: -Alexander.Belopolsky stage: -> unit test needed versions: +Python 3.2 -Python 2.6, Python 3.0 ___ Python tracker ___

[issue2736] datetime needs an "epoch" method

Alexander Belopolsky added the comment: On Fri, May 21, 2010 at 7:37 AM, Antoine Pitrou wrote: .. > I agree with Victor that the APIs need improving, even if it involves > providing obvious replacements of obscure one-liners. While I agree that the datetime API can be improved, I don't think

[issue2736] datetime needs an "epoch" method

Alexander Belopolsky added the comment: On Fri, May 21, 2010 at 7:26 AM, STINNER Victor 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 a possible fix to take care of the timezone inf

[issue2736] datetime needs an "epoch" method

Antoine Pitrou 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 inconsistent APIs. Just

[issue2736] datetime needs an "epoch" method

STINNER Victor 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 :-) I don't like mixing date

[issue2736] datetime needs an "epoch" method

Changes by Skip Montanaro : -- nosy: -skip.montanaro ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue2736] datetime needs an "epoch" method

Changes by Mark Dickinson : -- nosy: +amaury.forgeotdarc ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://

[issue2736] datetime needs an "epoch" method

Mark Dickinson 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 ___ Python

[issue2736] datetime needs an "epoch" method

Alexander Belopolsky 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 time.mktime(self.timetuple()) is