On Sun, Dec 30, 2012 at 11:19 AM, Steven D'Aprano st...@pearwood.infowrote:
If I've understood it correctly, that contradicts the PEP. One example
given is Etc/GMT+11, which is not a timezone *name*, but a timezone
name *plus an offset*. Presumably if GMT+11 is legal, so should be
GMT+10:30.
On 29/12/12 15:40, Lennart Regebro wrote:
On Sat, Dec 29, 2012 at 2:23 AM, Steven D'Apranost...@pearwood.infowrote:
The PEP says:
* New function :``timezone(name=None, db_path=None)``
This function takes a name string that must be a string specifying a
valid zoneinfo timezone, ie
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/30/2012 05:19 AM, Steven D'Aprano wrote:
There is no Etc/GMT+11 named here:
http://en.wikipedia.org/wiki/List_of_tz_database_time_zones
nor is it included in /usr/share/zoneinfo/zone.tab in either of the
systems I looked at (one Debian,
On Thu, Dec 20, 2012 at 5:43 PM, Barry Warsaw ba...@python.org wrote:
That would be `class UnknownTimeZoneError(ValueError, TimeZoneError)`.
As of today, in Pytz, UnknownTimeZoneError in fact subclasses KeyError.
Any opinions against that?
There is no TimeZoneError today, and it would only
On Dec 28, 2012, at 07:02 PM, Lennart Regebro wrote:
On Thu, Dec 20, 2012 at 5:43 PM, Barry Warsaw ba...@python.org wrote:
That would be `class UnknownTimeZoneError(ValueError, TimeZoneError)`.
As of today, in Pytz, UnknownTimeZoneError in fact subclasses KeyError. Any
opinions against
On 12/28/2012 1:02 PM, Lennart Regebro wrote:
On Thu, Dec 20, 2012 at 5:43 PM, Barry Warsaw ba...@python.org
mailto:ba...@python.org wrote:
That would be `class UnknownTimeZoneError(ValueError, TimeZoneError)`.
As of today, in Pytz, UnknownTimeZoneError in fact subclasses KeyError.
Any
On 29/12/12 05:02, Lennart Regebro wrote:
On Thu, Dec 20, 2012 at 5:43 PM, Barry Warsawba...@python.org wrote:
That would be `class UnknownTimeZoneError(ValueError, TimeZoneError)`.
As of today, in Pytz, UnknownTimeZoneError in fact subclasses KeyError.
Any opinions against that?
The
On Sat, Dec 29, 2012 at 2:23 AM, Steven D'Aprano st...@pearwood.infowrote:
The PEP says:
* New function :``timezone(name=None, db_path=None)``
This function takes a name string that must be a string specifying a
valid zoneinfo timezone, ie US/Eastern, Europe/Warsaw or
Etc/GMT+11.
On Dec 20, 2012, at 11:18 AM, Ben Finney wrote:
Terry Reedy tjre...@udel.edu writes:
On 12/12/2012 10:56 AM, Lennart Regebro wrote:
It seems like calling get_timezone() with an unknown timezone
should just throw ValueError, not necessarily some custom
Exception?
That could very well
Terry Reedy tjre...@udel.edu writes:
On 12/12/2012 10:56 AM, Lennart Regebro wrote:
It seems like calling get_timezone() with an unknown timezone
should just throw ValueError, not necessarily some custom
Exception?
That could very well be. What are others opinions on this?
OK, so it's been 12 hours with no further discussion, so I'll make an
attempt to summarize what I think is the consensus changes before
updating the PEP.
1. Python will include a timezone database both in the source
distribution and the Windows installer (although I suspect that binary
packages
Am 14.12.2012 09:31, schrieb Lennart Regebro:
1. Python will include a timezone database both in the source
distribution and the Windows installer (although I suspect that binary
packages for Linux distributions may skip this, but that's OK).
You need to specify the details. Where is the
On Dec 14, 2012, at 12:01 PM, Christian Heimes wrote:
* It's the release managers responsibility to make sure, all final
releases contain the current db. This needs to be added to the
RM's TODO list.
That would be PEP 101.
-Barry
___
Python-Dev
On 12/13/2012 1:06 AM, Lennart Regebro wrote:
On Thu, Dec 13, 2012 at 2:24 AM, Terry Reedy tjre...@udel.edu wrote:
Or ask the user where to put it.
If we ask where it should be installed, then we need a registry
setting for that
Right.
So I think that asking is not an option at all. It
On 12/12/2012 11:32 PM, Janzert wrote:
On 12/13/2012 1:39 AM, Glenn Linderman wrote:
On 12/12/2012 6:10 PM, Janzert wrote:
On 12/12/2012 8:43 PM, Glenn Linderman wrote:
On 12/12/2012 5:36 PM, Brian Curtin wrote:
C:\ProgramData\Python
^ That. Is not the path that the link
On Thu, Dec 13, 2012 at 9:22 AM, Terry Reedy tjre...@udel.edu wrote:
On 12/13/2012 1:06 AM, Lennart Regebro wrote:
All in all I would say I would prefer to install this per Python.
Then explicit update requires multiple downloads or copying. This is a
violation of DRY. If if is not too large,
Le Thu, 13 Dec 2012 10:07:34 +0100,
Lennart Regebro rege...@gmail.com a écrit :
On Thu, Dec 13, 2012 at 9:22 AM, Terry Reedy tjre...@udel.edu wrote:
On 12/13/2012 1:06 AM, Lennart Regebro wrote:
All in all I would say I would prefer to install this per Python.
Then explicit update
Am 13.12.2012 10:07, schrieb Lennart Regebro:
Yes, but this is no different that if you want to keep any library
updated over multiple Python versions. And I don't want to invent
another installation procedure that works for just this, or have a
little script that checks periodically for
On 12/13/2012 4:07 AM, Lennart Regebro wrote:
On Thu, Dec 13, 2012 at 9:22 AM, Terry Reedy tjre...@udel.edu wrote:
On 12/13/2012 1:06 AM, Lennart Regebro wrote:
All in all I would say I would prefer to install this per Python.
Then explicit update requires multiple downloads or copying. This
On 12 December 2012 00:58, Nick Coghlan ncogh...@gmail.com wrote:
I'd prefer a more aggressive name for this like tzdata_override. My
rationale is that *nix users need to thoroughly aware that if they install
this package, they will stop benefiting from the automatic tz database
updates
Am 12.12.2012 01:58, schrieb Nick Coghlan:
Ick, why a new module? Why not just add this directly to datetime? (It
doesn't need to be provided by the C accelerator, it can go straight in
the pure Python part).
+1 for something like datetime.timezone
How well does hg handle files renames? The
General comments:
It seems like the consensus is moving towards making sure there always is a
database available. If this means including it in the standard Python
distribution as well, or only on Windows, I don't know, opinions on that are
welcome.
The steps to look for a database would then
On Wed, Dec 12, 2012 at 9:56 AM, Lennart Regebro rege...@gmail.com wrote:
General comments:
It seems like the consensus is moving towards making sure there always is a
database available. If this means including it in the standard Python
distribution as well, or only on Windows, I don't
On Wed, Dec 12, 2012 at 4:56 PM, Lennart Regebro rege...@gmail.com wrote:
Why not keep a bit more of the pytz API to make porting easy?
The renaming of the timezone() function to get_timezone() is indeed small,
but changing pytz.timezone(foo) to timezone.timezone(foo) is really
significantly
On 12 December 2012 16:11, Brian Curtin br...@python.org wrote:
I don't think it's all that bad to include a small script on Windows
which runs every few days to check PyPI, then present an option to
update the info. This is what Java itself is doing anyway.
What would that do in an
Le Wed, 12 Dec 2012 10:11:15 -0600,
Brian Curtin br...@python.org a écrit :
I don't think it's all that bad to include a small script on Windows
which runs every few days to check PyPI, then present an option to
update the info. This is what Java itself is doing anyway.
I don't get why
On Wed, Dec 12, 2012 at 8:44 AM, Antoine Pitrou solip...@pitrou.net wrote:
Le Wed, 12 Dec 2012 10:11:15 -0600,
Brian Curtin br...@python.org a écrit :
I don't think it's all that bad to include a small script on Windows
which runs every few days to check PyPI, then present an option to
Paul Moore wrote:
On 12 December 2012 16:11, Brian Curtin br...@python.org wrote:
I don't think it's all that bad to include a small script on Windows
which runs every few days to check PyPI, then present an option to
update the info. This is what Java itself is doing anyway.
What would
Hi,
Le 12/12/2012 04:53, Christian Heimes a écrit :
Am 12.12.2012 01:58, schrieb Nick Coghlan:
Ick, why a new module? Why not just add this directly to datetime? (It
doesn't need to be provided by the C accelerator, it can go straight in
the pure Python part).
+1 for something like
On Tue, Dec 11, 2012 at 8:07 AM, Antoine Pitrou solip...@pitrou.net wrote:
Do we have statistics showing that Python
gets more use in summer?
Well, pythons are cold-blooded, so they're probably more
active during the warmer seasons...
--
Greg
___
On Wed, Dec 12, 2012 at 5:21 PM, Dirkjan Ochtman dirk...@ochtman.nl wrote:
That entirely depends on when you define to be the start. It seems
to me the consensus on python-dev has been that packages primarily
evolve outside the stdlib; it seems a bit weird to then, at the time
of stdlib
On Wed, Dec 12, 2012 at 5:54 PM, Steve Dower steve.do...@microsoft.com wrote:
Details of the registry entries are at
http://msdn.microsoft.com/en-us/library/ms725481.aspx. It looks like the data
is focused on modern timezones rather than localities, which would mean a
many-to-one mapping
On 12.12.12 02:43, Guido van Rossum wrote:
On Tue, Dec 11, 2012 at 5:11 PM, Robert Brewerfuman...@aminus.org wrote:
Guido van Rossum wrote:
Sent: Tuesday, December 11, 2012 4:11 PM
To: Antoine Pitrou
Cc:python-dev@python.org
Subject: Re: [Python-Dev] Draft PEP for time zone support.
On Tue
On 12/12/2012 11:53 AM, Guido van Rossum wrote:
Bingo. As long as the recipe to update is clear, most users can ignore
this, because the countries about which they care don't change DST
rules often enough for it to matter. When it does matter, they'll know
(changing the DST rules is something
On 12/12/2012 10:56 AM, Lennart Regebro wrote:
It seems like calling get_timezone() with an unknown timezone should
just throw ValueError, not necessarily some custom Exception?
That could very well be. What are others opinions on this?
ValueError. That is what it is. Nothing special here.
On Thu, Dec 13, 2012 at 12:23 AM, Terry Reedy tjre...@udel.edu wrote:
As a Windows user, I would like there to be one tz data file used by all
Python versions on my machine, including ones included with other apps.
That would be nice, but where would that be installed? There is no
standard
On 2012-12-12 23:33, Lennart Regebro wrote:
On Thu, Dec 13, 2012 at 12:23 AM, Terry Reedy tjre...@udel.edu wrote:
As a Windows user, I would like there to be one tz data file used by all
Python versions on my machine, including ones included with other apps.
That would be nice, but where
On Wed, Dec 12, 2012 at 6:10 PM, MRAB pyt...@mrabarnett.plus.com wrote:
On 2012-12-12 23:33, Lennart Regebro wrote:
On Thu, Dec 13, 2012 at 12:23 AM, Terry Reedy tjre...@udel.edu wrote:
As a Windows user, I would like there to be one tz data file used by all
Python versions on my machine,
On 12/12/2012 7:27 PM, Brian Curtin wrote:
On Wed, Dec 12, 2012 at 6:10 PM, MRAB pyt...@mrabarnett.plus.com wrote:
On 2012-12-12 23:33, Lennart Regebro wrote:
On Thu, Dec 13, 2012 at 12:23 AM, Terry Reedy tjre...@udel.edu wrote:
As a Windows user, I would like there to be one tz data file
On Dec 12, 2012 7:24 PM, Terry Reedy tjre...@udel.edu wrote:
On 12/12/2012 7:27 PM, Brian Curtin wrote:
On Wed, Dec 12, 2012 at 6:10 PM, MRAB pyt...@mrabarnett.plus.com wrote:
On 2012-12-12 23:33, Lennart Regebro wrote:
On Thu, Dec 13, 2012 at 12:23 AM, Terry Reedy tjre...@udel.edu wrote:
On 12/12/2012 5:36 PM, Brian Curtin wrote:
C:\ProgramData\Python
^ That. Is not the path that the link below is talking
about, though.
Making a new top-level directory without asking is obnoxious.
See
On 12/12/2012 8:43 PM, Glenn Linderman wrote:
On 12/12/2012 5:36 PM, Brian Curtin wrote:
C:\ProgramData\Python
^ That. Is not the path that the link below is talking
about, though.
It actually does; it is rather confusing though. :/ It's referring to
KNOWNFOLDERID constant
On Wed, Dec 12, 2012 at 8:10 PM, Janzert janz...@janzert.com wrote:
On 12/12/2012 8:43 PM, Glenn Linderman wrote:
On 12/12/2012 5:36 PM, Brian Curtin wrote:
C:\ProgramData\Python
^ That. Is not the path that the link below is talking
about, though.
It actually does; it is
On Thu, Dec 13, 2012 at 2:24 AM, Terry Reedy tjre...@udel.edu wrote:
Or ask the user where to put it.
If we ask where it should be installed, then we need a registry
setting for that or we don't know where it's located when it is to be
used. And if we ask, then people will install it in
On 12/12/2012 6:10 PM, Janzert wrote:
On 12/12/2012 8:43 PM, Glenn Linderman wrote:
On 12/12/2012 5:36 PM, Brian Curtin wrote:
C:\ProgramData\Python
^ That. Is not the path that the link below is talking
about, though.
It actually does; it is rather confusing though. :/
On 12/13/2012 1:39 AM, Glenn Linderman wrote:
On 12/12/2012 6:10 PM, Janzert wrote:
On 12/12/2012 8:43 PM, Glenn Linderman wrote:
On 12/12/2012 5:36 PM, Brian Curtin wrote:
C:\ProgramData\Python
^ That. Is not the path that the link below is talking
about, though.
It
This PEP is also available on github:
https://github.com/regebro/tz-pep/blob/master/pep-04tz.txt
Text:
PEP: 4??
Title: Time zone support improvements
Version: $Revision$
Last-Modified: $Date$
Author: Lennart Regebro rege...@gmail.com
BDFL-Delegate: Barry Warsaw
Status: Draft
Type: Standards
On Tue, Dec 11, 2012 at 4:23 PM, Lennart Regebro rege...@gmail.com wrote:
Proposal
The time zone support will be implemented by a new module called `timezone``,
based on Stuart Bishop's ``pytz`` module.
I wonder if there needs to be something here about how to port from
pytz to the
On 11 December 2012 15:39, Dirkjan Ochtman dirk...@ochtman.nl wrote:
Should the windows installer include the data package?
--
It has been suggested that the Windows installer should include the data
package. This would mean that an explicit
On Tue, Dec 11, 2012 at 9:48 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 11 December 2012 15:39, Dirkjan Ochtman dirk...@ochtman.nl wrote:
Should the windows installer include the data package?
--
It has been suggested that the Windows
Le Tue, 11 Dec 2012 16:23:37 +0100,
Lennart Regebro rege...@gmail.com a écrit :
Changes in the ``datetime``-module
--
A new ``is_dst`` parameter is added to several of the `tzinfo`
methods to handle time ambiguity during DST changeovers.
*
On Dec 11, 2012, at 04:23 PM, Lennart Regebro wrote:
This PEP is also available on github:
https://github.com/regebro/tz-pep/blob/master/pep-04tz.txt
wget returns some html gobbledygook. Why-oh-why github?!
PEP: 4??
I've assigned this PEP 431, reformatted a few extra wide paragraphs,
On Tuesday, December 11, 2012 at 3:31 PM, Barry Warsaw wrote:
On Dec 11, 2012, at 04:23 PM, Lennart Regebro wrote:
This PEP is also available on github:
https://github.com/regebro/tz-pep/blob/master/pep-04tz.txt
wget returns some html gobbledygook. Why-oh-why github?!'
wget
Barry you want github raw:
https://raw.github.com/regebro/tz-pep/master/pep-04tz.txt
On Tue, Dec 11, 2012 at 3:31 PM, Barry Warsaw ba...@python.org wrote:
On Dec 11, 2012, at 04:23 PM, Lennart Regebro wrote:
This PEP is also available on github:
On Tue, Dec 11, 2012 at 8:07 AM, Antoine Pitrou solip...@pitrou.net wrote:
Le Tue, 11 Dec 2012 16:23:37 +0100,
Lennart Regebro rege...@gmail.com a écrit :
Changes in the ``datetime``-module
--
A new ``is_dst`` parameter is added to several of the `tzinfo`
On Wed, Dec 12, 2012 at 1:23 AM, Lennart Regebro rege...@gmail.com wrote:
Abstract
This PEP proposes the implementation of concrete time zone support in the
Python standard library, and also improvements to the time zone API to deal
with ambiguous time specifications during DST
Guido van Rossum wrote:
Sent: Tuesday, December 11, 2012 4:11 PM
To: Antoine Pitrou
Cc: python-dev@python.org
Subject: Re: [Python-Dev] Draft PEP for time zone support.
On Tue, Dec 11, 2012 at 8:07 AM, Antoine Pitrou solip...@pitrou.net
wrote:
Le Tue, 11 Dec 2012 16:23:37 +0100
Great work, Lennart. I really like this PEP. Feedback follows (I haven't yet
read the rest of the messages in this thread ;).
On Dec 11, 2012, at 04:23 PM, Lennart Regebro wrote:
This PEP proposes to add these ``is_dst`` parameters to the relevant methods
of the ``datetime`` API, and therefore
On Dec 11, 2012, at 03:48 PM, Paul Moore wrote:
I agree. Also, in corporate or similar environments where each
individual package installation must be approved, having at least some
timezone data in the base install ensures that all Python code can
assume the *existence* of timezone support (if
On Dec 11, 2012, at 03:37 PM, Brandon W Maister wrote:
Barry you want github raw:
https://raw.github.com/regebro/tz-pep/master/pep-04tz.txt
I found that out. I was mostly just complaining. ;)
-Barry
signature.asc
Description: PGP signature
___
On Dec 11, 2012, at 03:31 PM, Barry Warsaw wrote:
I've assigned this PEP 431, reformatted a few extra wide paragraphs, committed
and pushed.
Unfortunately, it looks like the online PEP updater isn't working.
-Barry
signature.asc
Description: PGP signature
On Dec 11, 2012, at 04:23 PM, Lennart Regebro wrote:
A new ``is_dst`` parameter is added to several of the `tzinfo` methods to
handle time ambiguity during DST changeovers.
``None`` will raise an ``AmbiguousTimeError`` exception if the time specified
was during a DST change over. It will also
On Wed, Dec 12, 2012 at 12:58 PM, Barry Warsaw ba...@python.org wrote:
On Dec 11, 2012, at 04:23 PM, Lennart Regebro wrote:
A new ``is_dst`` parameter is added to several of the `tzinfo` methods to
handle time ambiguity during DST changeovers.
``None`` will raise an ``AmbiguousTimeError``
On Dec 12, 2012, at 01:14 PM, Nick Coghlan wrote:
That's a backwards compatibility risk, though - many applications are
likely coping just fine with the slightly corrupted time values, but would
fall over if an exception was raised instead. The default should probably
be chosen so that the single
On Tue, Dec 11, 2012 at 7:19 PM, Barry Warsaw ba...@python.org wrote:
On Dec 12, 2012, at 01:14 PM, Nick Coghlan wrote:
That's a backwards compatibility risk, though - many applications are
likely coping just fine with the slightly corrupted time values, but would
fall over if an exception was
On Tue, Dec 11, 2012 at 5:11 PM, Robert Brewer fuman...@aminus.org wrote:
Guido van Rossum wrote:
Sent: Tuesday, December 11, 2012 4:11 PM
To: Antoine Pitrou
Cc: python-dev@python.org
Subject: Re: [Python-Dev] Draft PEP for time zone support.
On Tue, Dec 11, 2012 at 8:07 AM, Antoine Pitrou
66 matches
Mail list logo
