Mark Dickinson dicki...@gmail.com added the comment:
issue5904g.diff looks good to me. A very nice piece of work!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5094
___
Mark Dickinson dicki...@gmail.com added the comment:
The latest patch looks good to me. I only have minor comments, in random order:
- Should the PyDateTime_TimeZone struct definition go into datetime.h, so that
it's avaiable if you want to export any C-API functions later on?
- If you're
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Sun, Jun 13, 2010 at 10:09 AM, Mark Dickinson rep...@bugs.python.org wrote:
..
- Should the PyDateTime_TimeZone struct definition go into
datetime.h, so that it's avaiable if you want to export any C-API
functions
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Just to add a little bit of historical perspective, this proposal is really
more than seven years old:
s.keim (Dec 20, 2002 3:33 am; Comment #13)
.. do we really need methods like utcnow. I believe the following could
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
issue5094g.diff addresses all Mark's suggestions except making struct
definition public. I also made a few other changes:
1. Constructor now raises TypeError when offset is not a timedelta instead of
ValueError in
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Also I changed Py_DECREFs in destructor to Py_CLEAR. I understand that while
not strictly required in this case, it is a good practice.
--
___
Python tracker
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
I have made my mind on subclassing timezone issue. I believe subclassing
should not be allowed and here is the reason:
The new datetime.timezone class is a very specific implementation of tzinfo
interface. It
Mark Dickinson dicki...@gmail.com added the comment:
I agree it seems fine to disallow subclassing of timezone. (And if we decide,
in the light of new information, that that was wrong, then it's easy to allow
subclassing later; harder to disallow it.)
+1 for 'UTC±HH:MM' for both tzname and
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
+1 for 'UTC±HH:MM' for both tzname and __str__, too.
It looks like I subconsciently allocated enough characters for this in the
string buffer, so now this is a single character change. I'll do it with other
changes (if
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Attaching issue5094f.diff which implements 'UTC±HH:MM' and adds unit tests for
more error cases.
--
Added file: http://bugs.python.org/file17648/issue5094f.diff
___
Python
Mark Dickinson dicki...@gmail.com added the comment:
I'm not sure if I missed this in the earlier discussion: is there a reason to
prevent subclassing of timezone?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5094
Mark Dickinson dicki...@gmail.com added the comment:
Some comments from playing with this patch (without having looked at the
implementation):
- As noted above, the 'timezone' class can't be subclassed. Is this
deliberate? I notice that Brett said let users subclass as needed to add DST
Mark Dickinson dicki...@gmail.com added the comment:
One more: there's a footnote marked in the docs (line 36 of datetime.rst), but
no corresponding footnote as far as I can see.
--
___
Python tracker rep...@bugs.python.org
Mark Dickinson dicki...@gmail.com added the comment:
And another minor doc issue: the docs still say:
The datetime module does not supply any concrete subclasses of tzinfo.
--
___
Python tracker rep...@bugs.python.org
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Fri, Jun 11, 2010 at 10:23 AM, Mark Dickinson rep...@bugs.python.org wrote:
..
Some comments from playing with this patch (without having looked at the
implementation):
thank you very much for your comments. As we
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
I have to stop replying to emails. There is no reason behind roundup remove
comments logic. Reposting my message:
On Fri, Jun 11, 2010 at 10:23 AM, Mark Dickinson rep...@bugs.python.org wrote:
..
Some comments from
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
I am attaching a new patch, issue5094e.diff which addresses most of Mark's
comments. I left out repr() because two opinions were voiced on IRC with
respect to datetime. prefix. I would like to give it some more thought
akira 4kir4...@gmail.com added the comment:
Minor notes:
msg107186:
1. The constructor now accepts only whole number of minutes in [-23:59,
23:59] range.
rfc 3339 provides the following example:
1937-01-01T12:00:27.87+00:20
This represents the same instant of time as noon, January
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
There is a separate issue #5288 asking to support sub-minute offsets. This is
not hard, but the C code still has a few interfaces left from the time when
offset was an integer # of minutes. I am +1 to fix that, but not
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Readying the patch for commit. Added documentation, tests and implementation
of fromutc() method that does not need a dst().
--
resolution: - accepted
Added file: http://bugs.python.org/file17585/issue5094d.diff
Daniel Urban urban.dani...@gmail.com added the comment:
In Doc/library/datetime.rst, in the documentation of datetime.utcnow this part:
.. versionchanged:: 2.7 probably should be .. versionchanged:: 3.2.
--
___
Python tracker rep...@bugs.python.org
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Thanks, Daniel. This was a leftover from the previous patch. The latest patch
does not actually change utcnow(). Instead the users should call
datetime.now(timezone.utc). Fixed in issue5094d1.diff.
--
Added
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
I am attaching the next version of my patch and changing priority to high
because it appears that several issues depend on resolution of this one.
Here is the summary of changes since issue5094a.diff:
1. The constructor
Daniel Urban urban.dani...@gmail.com added the comment:
Isn't it possible, that in the issue5094b.diff patch, in the new_timezone_ex
function, in this part:
self = (PyDateTime_TimeZone *)type-tp_alloc(type, 0);
if (self == NULL)
return NULL;
should be a Py_DECREF(offset) call?
I mean
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Good catch, Daniel!
Fixed in issue5094c.diff.
--
Added file: http://bugs.python.org/file17570/issue5094c.diff
___
Python tracker rep...@bugs.python.org
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
nosy: -haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5094
___
___
Brett Cannon br...@python.org added the comment:
Put yourself down as the maintainer of datetime in Misc/maintainers.rst and you
have a deal, Alexander! =)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5094
anatoly techtonik techto...@gmail.com added the comment:
On Fri, Jun 4, 2010 at 11:09 PM, Brett Cannon rep...@bugs.python.org wrote:
Unless other people step forward to debate this we probably are not going to
reach consensus without going to python-dev to see what others think.
I would
Brett Cannon br...@python.org added the comment:
I'm still leary of supporting any form of DST. A proper DST implementation
would need to have some conditional code to account for the datetime object
passed into dst, and yet the version you have prototyped doesn't handle it. So
a proper
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Thu, Jun 3, 2010 at 3:19 PM, Mark Dickinson rep...@bugs.python.org wrote:
..
Aren't there valid timezones that are offset by more than 12 hours from UTC?
Indeed, Christmas Island uses UTC+14.
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Merging in issue7584 nosy list.
--
nosy: +durban, l0nwlf, r.david.murray, techtonik
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5094
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
I'm still leary of supporting any form of DST. A proper DST
implementation would need to have some conditional code to
account for the datetime object passed into dst, and yet the
version you have prototyped doesn't
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
--
nosy: +tim_one
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5094
___
___
Brett Cannon br...@python.org added the comment:
For the allowable range, follow the datetime docs as someone might be relying
on that specification already.
As for the ongoing DST debate, it seems we either need to say that since we
cannot properly support all possible datetimes properly we
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Fri, Jun 4, 2010 at 4:09 PM, Brett Cannon rep...@bugs.python.org wrote:
..
For the allowable range, follow the datetime docs as someone might be relying
on that specification already.
Will do. I think it is as
Brett Cannon br...@python.org added the comment:
On Fri, Jun 4, 2010 at 15:17, Alexander Belopolsky
rep...@bugs.python.org wrote:
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Fri, Jun 4, 2010 at 4:09 PM, Brett Cannon rep...@bugs.python.org wrote:
..
For the
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
I am attaching the next installment of the datetime.timezone class
implementation.
Here I add ``utc`` class attribute to timezone. I decided to place it in class
rather than module namespace because this seems to be
Brett Cannon br...@python.org added the comment:
I don't think people would get confused as to what datetime.utc was, but as you
pointed out, Alexander, the module seems to like class attributes so
timezone.utc is fine.
As for the float/int argument, I personally am wary of it. Since the
Mark Dickinson dicki...@gmail.com added the comment:
accept arbitrary timedelta between timedelta(hours=-12) and
timedelta(hours=12)
Aren't there valid timezones that are offset by more than 12 hours from UTC?
--
nosy: +mark.dickinson
___
Python
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Thu, Jun 3, 2010 at 3:19 PM, Mark Dickinson rep...@bugs.python.org wrote:
..
Aren't there valid timezones that are offset by more than 12 hours from UTC?
I am not sure. At this stage treat 12 as a placeholder for
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Thu, Jun 3, 2010 at 3:41 PM, Alexander Belopolsky
rep...@bugs.python.org wrote:
..
I am not sure. At this stage treat 12 as a placeholder for whatever
the relevant standard says.
Believe it or not, at least one
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Thu, Jun 3, 2010 at 3:15 PM, Brett Cannon rep...@bugs.python.org wrote:
..
As for the float/int argument, I personally am wary of it. Since the
timedelta constructor accepts hours as a keyword argument, I don't
see
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
--
assignee: - belopolsky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5094
___
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
I am having second thoughts about dst indicator. I wrote:
2. Do we want to add a dst indicator and altname attributes? I would say: no. I
would rather treat DST as a different fixed offset timezone.
and Brett
Brett Cannon br...@python.org added the comment:
So you want a third argument that lets you flag if the timezone is DST or not?
I still don't think that will be necessary. If people want to add that they can
very easily subclass the timezone class and add support for it. This class
should be
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Here is my first attempt to implement fixed offset timezone type. The patch is
based on Brett's next-patch.txt and while I changed the type name from
datetime.UTC to datetime.timezone, I did not change the name of the
Brett Cannon br...@python.org added the comment:
My thoughts on Alexander's questions:
1. Call it FixedTimezone or something (remember it has to be CapWords). Calling
it simply Timezone does not convey the fact that DST is not supported and
people might naively think it will. Its limited
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Wed, Jun 2, 2010 at 5:24 PM, Brett Cannon rep...@bugs.python.org wrote:
..
1. Call it FixedTimezone or something (remember it has to be CapWords).
I thought consistency within module trumps PEP 8 naming standards.
The
Brett Cannon br...@python.org added the comment:
Forgot about datetime breaking the PEP 8 rules. You're right, consistency wins.
As for fixedtimezone being odd, that's why my mind went with
FixedOffsetTimezone to start, but that doesn't go with the naming of the
module, and
Antoine Pitrou pit...@free.fr added the comment:
The second is whether we should take this opportunity to fix datetime
being a C extension module exclusively. I know PyPy has their own pure
Python version of datetime that they plan to eventually contribute. We
might as well use this as the
Brett Cannon br...@python.org added the comment:
PyPy has said over the years they plan to commit their version of datetime,
they just need to get around to it. I just figured that we could use this
opportunity to prepare for it. But if people want to do the C version first,
that's fine as
Antoine Pitrou pit...@free.fr added the comment:
Note that I am not suggesting passing anything to utcnow(). I would
either leave it unchanged or make it always return aware datetime
instances.
The latter would break compatibility, though (especially given how
comparison between naive and
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Tue, May 25, 2010 at 5:45 AM, Antoine Pitrou rep...@bugs.python.org wrote:
..
I also agree with Brett that a singleton looks rather unnecessary (it
also look quite C++/Java-esque to me).
I still don't understand your
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Mon, May 24, 2010 at 11:06 PM, Rafe Kaplan rep...@bugs.python.org wrote:
..
I had originally thought of doing the class, and then having constants
associated with it:
UTC.UTC0
Eventually if we support multiple
Brett Cannon br...@python.org added the comment:
The singleton dislike from Antoine and me is that they are generally just not
liked in the stdlib. None/True/False are special cases because they are syntax,
so having ``None is None`` ever not work would just be weird. Otherwise
singletons are
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
..
Thanks for the explanation. I realize that I should not have used the
s-word. :-) In fact I only wanted a module level constant utc = UTC()
and did not care much about other UTC class instances and whether any
are
Rafe Kaplan ra...@google.com added the comment:
Note that I am not suggesting passing anything to utcnow(). I would
either leave it unchanged or make it always return aware datetime
instances.
FYI, all other issues aside, having utcnow() (with no parameters) return a
tzaware instance will
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Roundup bug bites again. Reposting via web:
-
On Tue, May 25, 2010 at 5:35 PM, Brett Cannon rep...@bugs.python.org wrote:
The singleton dislike from Antoine and me is that they are generally just not
liked in the
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Note that Brett has already mentioned backward compatibility issues, but
suggested that [adding tz_aware argument may provide] a transition plan to
make utcnow() always return a timezone-aware datetime object. [msg106413]
Brett Cannon br...@python.org added the comment:
If we don't modify utcnow (and similar UTC methods) to take a flag saying to
use the utc instance, then the methods should at least get deprecated with a
message saying that people should be using ``now(utc)``, etc.
--
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Brett: [utcnow] should at least get deprecated with a message saying that
people should be using ``now(utc)``
Yes, I believe all utcxxx methods of datetime are a kludge due to the lack of
concrete UTC tzinfo:
Brett Cannon br...@python.org added the comment:
OK, it looks like we are reaching consensus here on several points:
1. Implement FixedOffsetTimezone
2. Provide a utc attribute on the datetime module that is set to
``FixedOffsetTimezone(0, UTC)``
3. Deprecate the various utc* methods with
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
I have no opinion on the first question. I would be fine with a simple soft
deprecation where we simply add a note in documentation warning that these
methods create naive datetime instances and it is preferable to use
Brett Cannon br...@python.org added the comment:
The stated long-term goal of the stdlib is to minimize the C extension modules
to only those that have to be written in C (modules can still have performance
enhancing extension back-ends). Since datetime does not meet that requirement
it's not
Brett Cannon br...@python.org added the comment:
Attaching a new patch by Rafe against Python 2.7. Unfortunately with 2.7
striving for an RC next, this should only target Python 3.2 and not 2.7.
--
versions: +Python 3.2 -Python 2.7, Python 3.1
Added file:
Changes by Brett Cannon br...@python.org:
Removed file: http://bugs.python.org/file13023/datetime-utc.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5094
___
Changes by Brett Cannon br...@python.org:
Removed file: http://bugs.python.org/file13029/datetime-utc-doc.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5094
___
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
I have two questions about the proposed implementation:
1. Why not follow pytz lead and expose an instance of UTC rather than the UTC
class itself?
2. Is there a real need to add a boolean argument to utcnow()? I think
Rafe Kaplan ra...@google.com added the comment:
Alexander, about 1, that's a pretty good question. I had originally wanted to
do something like that but Brett Cannon at the time thought it was not the
right approach. I don't recall the details. Maybe Brett can recall. I think
we had that
Brett Cannon br...@python.org added the comment:
We didn't do a singleton because I don't like singletons. =) Plus they muck
with isinstance/issubclass if you don't expose the class. Basically there is no
need to have it be a singleton, so why bother?
And Rafe is right: since utcnow() already
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Mon, May 24, 2010 at 11:06 PM, Rafe Kaplan rep...@bugs.python.org wrote:
..
On 2, we had discussions about how to pass parameters in to utcnow that we
DID record. When I
suggested it, Brett said:
...using a
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
We didn't do a singleton because I don't like singletons. =) Plus they
muck with isinstance/issubclass if you don't expose the class.
I am not sure what you mean by muck with. Why would anyone want to subclass
UTC?
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
--
nosy: +belopolsky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5094
___
___
Changes by Éric Araujo mer...@netwok.org:
--
nosy: +merwok
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5094
___
___
Python-bugs-list mailing
Changes by Brett Cannon br...@python.org:
--
assignee: brett.cannon -
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5094
___
___
Python-bugs-list
Brett Cannon br...@python.org added the comment:
I am currently doing a review of the patch over at
http://codereview.appspot.com/22042 .
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5094
___
Walter Dörwald wal...@livinglogic.de added the comment:
The patch doesn't include any changes to the documentation.
--
nosy: +doerwalter
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5094
Rafe Kaplan ra...@google.com added the comment:
I thought I had uploaded this last night, apologies.
Added file: http://bugs.python.org/file13029/datetime-utc-doc.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5094
Changes by Rafe Kaplan ra...@google.com:
--
keywords: +patch
Added file: http://bugs.python.org/file13023/datetime-utc.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5094
___
Changes by Brett Cannon br...@python.org:
--
stage: test needed - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5094
___
___
STINNER Victor victor.stin...@haypocalc.com added the comment:
The UTC class have to be converted to C. Can someone write a patch for
datetimemodule.c (and the doc plus an unit test ;-))?
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
Brett Cannon br...@python.org added the comment:
On Tue, Feb 3, 2009 at 03:28, STINNER Victor rep...@bugs.python.org wrote:
STINNER Victor victor.stin...@haypocalc.com added the comment:
The UTC class have to be converted to C.
Yes, the example code is just an example. =)
Can someone
Changes by Brett Cannon br...@python.org:
--
assignee: - brett.cannon
stage: needs patch - test needed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5094
___
Rafe Kaplan ra...@google.com added the comment:
I'm going to attempt to implement this feature.
--
nosy: +rafe
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5094
___
Changes by Brett Cannon br...@python.org:
--
priority: - low
stage: - needs patch
type: - feature request
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5094
___
Antoine Pitrou pit...@free.fr added the comment:
Please do. The current situation where the doc tells you not to use
naive datetime objects but Python gives you no way to do so is awful.
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
Gabriel Genellina gagsl-...@yahoo.com.ar added the comment:
Seems perfectly reasonable to me.
--
nosy: +gagenellina
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5094
___
HiroakiKawai ka...@apache.org added the comment:
I want UTC tzinfo. too.
--
nosy: +kawai
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5094
___
New submission from Brett Cannon br...@python.org:
When you call datetime.datetime.utcnow() you get back a naive datetime
object. But why? You asked for UTC as the timezone based on what method
call you made. And UTC is a very concrete timezone that never changes.
It would be nice to have a
Daniel Diniz aja...@gmail.com added the comment:
Brett,
It might be worth to update tzinfo-examples.py to use your concrete UTC
then:
http://svn.python.org/view/python/trunk/Doc/includes/tzinfo-examples.py?rev=62214view=markup
--
nosy: +ajaksu2
___
Brett Cannon br...@python.org added the comment:
On Wed, Jan 28, 2009 at 18:17, Daniel Diniz rep...@bugs.python.org wrote:
Daniel Diniz aja...@gmail.com added the comment:
Brett,
It might be worth to update tzinfo-examples.py to use your concrete UTC
then:
I will if people are generally
91 matches
Mail list logo
