On Sun, Dec 30, 2012 at 11:19 AM, Steven D'Aprano wrote:
> 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.
>
This depend
-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 D
On 29/12/12 15:40, Lennart Regebro wrote:
On Sat, Dec 29, 2012 at 2:23 AM, Steven D'Apranowrote:
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/Wa
On Sat, Dec 29, 2012 at 2:23 AM, Steven D'Aprano wrote:
> 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".
>
>
> It i
On 29/12/12 05:02, Lennart Regebro wrote:
On Thu, Dec 20, 2012 at 5:43 PM, Barry Warsaw wrote:
That would be `class UnknownTimeZoneError(ValueError, TimeZoneError)`.
As of today, in Pytz, UnknownTimeZoneError in fact subclasses KeyError.
Any opinions against that?
The PEP says:
* New
On 12/28/2012 1:02 PM, Lennart Regebro wrote:
On Thu, Dec 20, 2012 at 5:43 PM, Barry Warsaw mailto: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 Dec 28, 2012, at 07:02 PM, Lennart Regebro wrote:
>On Thu, Dec 20, 2012 at 5:43 PM, Barry Warsaw wrote:
>
>>
>> That would be `class UnknownTimeZoneError(ValueError, TimeZoneError)`.
>>
>
>As of today, in Pytz, UnknownTimeZoneError in fact subclasses KeyError. Any
>opinions against that? The
On Thu, Dec 20, 2012 at 5:43 PM, Barry Warsaw 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 be used for thi
On Dec 20, 2012, at 11:18 AM, Ben Finney wrote:
>Terry Reedy 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 ver
Terry Reedy 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?
>
> ValueErro
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
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 dat
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 fo
On 12/13/2012 4:07 AM, Lennart Regebro wrote:
On Thu, Dec 13, 2012 at 9:22 AM, Terry Reedy 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 o
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 up
Le Thu, 13 Dec 2012 10:07:34 +0100,
Lennart Regebro a écrit :
> On Thu, Dec 13, 2012 at 9:22 AM, Terry Reedy 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
On Thu, Dec 13, 2012 at 9:22 AM, Terry Reedy 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, it would n
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 be
On 12/13/2012 1:06 AM, Lennart Regebro wrote:
On Thu, Dec 13, 2012 at 2:24 AM, Terry Reedy 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 either goes in
%PRO
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 actu
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 Thu, Dec 13, 2012 at 2:24 AM, Terry Reedy 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 non-standard
locations.
On Wed, Dec 12, 2012 at 8: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 do
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 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
http://stackoverflow.com/questions/9518890/what-is-the-significanc
On Dec 12, 2012 7:24 PM, "Terry Reedy" wrote:
>
> On 12/12/2012 7:27 PM, Brian Curtin wrote:
>>
>> On Wed, Dec 12, 2012 at 6:10 PM, MRAB wrote:
>>>
>>> On 2012-12-12 23:33, Lennart Regebro wrote:
On Thu, Dec 13, 2012 at 12:23 AM, Terry Reedy wrote:
>
>
> As a Windows u
On 12/12/2012 7:27 PM, Brian Curtin wrote:
On Wed, Dec 12, 2012 at 6:10 PM, MRAB wrote:
On 2012-12-12 23:33, Lennart Regebro wrote:
On Thu, Dec 13, 2012 at 12:23 AM, Terry Reedy wrote:
As a Windows user, I would like there to be one tz data file used by all
Python versions on my machine, i
On Wed, Dec 12, 2012 at 6:10 PM, MRAB wrote:
> On 2012-12-12 23:33, Lennart Regebro wrote:
>>
>> On Thu, Dec 13, 2012 at 12:23 AM, Terry Reedy 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 ot
On 2012-12-12 23:33, Lennart Regebro wrote:
On Thu, Dec 13, 2012 at 12:23 AM, Terry Reedy 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 install
On Thu, Dec 13, 2012 at 12:23 AM, Terry Reedy 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 location for zonein
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 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 th
On 12.12.12 02:43, Guido van Rossum wrote:
On Tue, Dec 11, 2012 at 5:11 PM, Robert Brewer 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
On Wed, Dec 12, 2012 at 5:54 PM, Steve Dower 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 from zoneinfo. Unfortuna
On Wed, Dec 12, 2012 at 5:21 PM, Dirkjan Ochtman 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 inclusion, start ch
On Tue, Dec 11, 2012 at 8:07 AM, Antoine Pitrou 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
___
Python-Dev mailing li
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
Paul Moore wrote:
> On 12 December 2012 16:11, Brian Curtin 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
On Wed, Dec 12, 2012 at 8:44 AM, Antoine Pitrou wrote:
> Le Wed, 12 Dec 2012 10:11:15 -0600,
> Brian Curtin 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 J
Le Wed, 12 Dec 2012 10:11:15 -0600,
Brian Curtin 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 people are so obse
On 12 December 2012 16:11, Brian Curtin 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 environment without inte
On Wed, Dec 12, 2012 at 4:56 PM, Lennart Regebro 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 easier than
On Wed, Dec 12, 2012 at 9:56 AM, Lennart Regebro 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 know, opinions o
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 ch
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
On 12 December 2012 00:58, Nick Coghlan 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 provided by their O
On Tue, Dec 11, 2012 at 5:11 PM, Robert Brewer 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 Tue, Dec 11, 2012 at 7:19 PM, Barry Warsaw 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 raised ins
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 sin
On Wed, Dec 12, 2012 at 12:58 PM, Barry Warsaw 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`` exception
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 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 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
___
Pyt
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 (i
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 therefor
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
> wrote:
> > Le Tue, 11 Dec 2012
On Wed, Dec 12, 2012 at 1:23 AM, Lennart Regebro 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 changes.
>
Tha
On Tue, Dec 11, 2012 at 8:07 AM, Antoine Pitrou wrote:
> Le Tue, 11 Dec 2012 16:23:37 +0100,
> Lennart Regebro a écrit :
>>
>> Changes in the ``datetime``-module
>> --
>>
>> A new ``is_dst`` parameter is added to several of the `tzinfo`
>> methods to handle tim
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 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-04
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 h
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, comm
Le Tue, 11 Dec 2012 16:23:37 +0100,
Lennart Regebro 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.
>
> * ``tzinfo.utcoffset(se
On Tue, Dec 11, 2012 at 9:48 AM, Paul Moore wrote:
> On 11 December 2012 15:39, Dirkjan Ochtman wrote:
>>> Should the windows installer include the data package?
>>> --
>>>
>>> It has been suggested that the Windows installer should include the
On 11 December 2012 15:39, Dirkjan Ochtman 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 installa
On Tue, Dec 11, 2012 at 4:23 PM, Lennart Regebro 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 new timezone
65 matches
Mail list logo
