subject:"\[Python\-Dev\] Draft PEP for time zone support."

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 change to:

  1. The path specified, if not None.

  2. The module for timezone overrides.

  3. The OS database.

  4. The database included in Python.

We need to determine if a warning should be raised in case of 4 or not, as
well as the name for the override module. I think the word override here is
possibly unclear, I'd prefer something like timezone-update or similar.

I'm personally a bit sceptical to writing a special updater/installer just
for this. I don't want to have a special unique way to install this package.

As it comes to OS packages, Christian Heimes pointed out that most Windows
installations today has Java installed, and kept updated, and it has a
zoneinfo database. We could consider using that on Windows as well, although
it admittedly feels quite icky.

I haven't been able to find any other common locations for the
zoneinfo database on Windows.



Specific answers:

On Tue, Dec 11, 2012 at 4:39 PM, Dirkjan Ochtman dirk...@ochtman.nl wrote:

 I wonder if there needs to be something here about how to port from
 pytz to the new timezone library.

It would be nice to have, but I don't think it's necessary to have in the PEP.

 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?

 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 renaming it to timezone.get_timezone(foo).

If we keep all of the API intact you could do

try:
import pytz as timezone
except ImportError:
import timezone

Which would make porting quicker, that's true, but do we really want to keep
unecessary API's around forever? Isn't it better to minimize the noise from
the start?

 It also seems relatively painless to keep localize() and normalize()
 functions around for easy porting.

Sure, but you then have two ways of doing the same thing, which I think we
should avoid.


On Tue, Dec 11, 2012 at 5:07 PM, Antoine Pitrou solip...@pitrou.net wrote:

 The ``is_dst`` parameter can be ``True`` (default), ``False``, or
 ``None``.

 Why is it True by default? Do we have statistics showing that Python
 gets more use in summer?

Because for some reason both me and Stuart Bishop thought it should be, but
at least in my case I don't have any actual good reason why. Checking with
how pytz does this shows that pytz in fact defaults to False, so I think
the default should be False.


On Wed, Dec 12, 2012 at 3:50 AM, Barry Warsaw ba...@python.org wrote:

 This is likely the hardest part of this PEP as this involves updating the

 Oops, something got cut off there.

Ah, yes, I was going to write that the difficult bit was updating the
_datetime.c module.

 Why add a new module instead of putting all this into the existing datetime
 module, either directly or as a submodule? Seems like the obvious place to
 put it instead of claiming another top-level module name.

pytz as it is consists of several modules, and a significant amount of code,
it didn't feel right to move all that into the datetime.py module. It also
didn't feel right to then not implement it in _datetime.c, but perhaps that's
just me being silly.

But a submodule could work.

 I'm bikeshedding, but can we find a better name than `db` for the second
 argument?  Something that makes it obvious we're looking for file system path?

Absolutely. db_path?

 I'd really like to see a TimeZoneError base class from which all these new
 exceptions inherit.

That makes sense.

The ``timezonedata``-package
-

 Just to be clear, this doesn't expose any new modules, right?

That's the intention, yes, although I haven't investigated ways of knowing if
it's installed or not yet, and exposing a module is the obvious way of doing
that. But I'm hoping there will be better ways, right?

 One other thing that the PEP should describe is what happens on a distro that
 has timezone data, but which you also pip install the PyPI tzdata package.
 Which one wins?  Is there a way to control it, other than providing an
 explicit path?  Is there a way to uninstall the PyPI package?  Does the API
 need to provide a method which tells you where the database it is using by
 default lives?

The PyPI package wins, I'll clarify that bit. I'm think the data should end
up in site-packages somewhere, and that it should be installable and
uninstallable with pip/easy_install and by simply deleting it.


On Wed, Dec 12, 2012 at 4:14 AM, Nick Coghlan

Re: [Python-Dev] Draft PEP for time zone support.

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 know, opinions on that are
 welcome.

 The steps to look for a database would then change to:

   1. The path specified, if not None.

   2. The module for timezone overrides.

   3. The OS database.

   4. The database included in Python.

 We need to determine if a warning should be raised in case of 4 or not, as
 well as the name for the override module. I think the word override here is
 possibly unclear, I'd prefer something like timezone-update or similar.

 I'm personally a bit sceptical to writing a special updater/installer just
 for this. I don't want to have a special unique way to install this package.

 As it comes to OS packages, Christian Heimes pointed out that most Windows
 installations today has Java installed, and kept updated, and it has a
 zoneinfo database. We could consider using that on Windows as well, although
 it admittedly feels quite icky.

Depending on Java being installed or even installing it alongside
Python would be a funny April Fools prank. This can't happen.

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.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

2012-12-12 Thread Dirkjan Ochtman

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 easier than renaming it to timezone.get_timezone(foo).

 If we keep all of the API intact you could do

 try:
 import pytz as timezone
 except ImportError:
 import timezone

 Which would make porting quicker, that's true, but do we really want to keep
 unecessary API's around forever? Isn't it better to minimize the noise from
 the start?

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 changing the API.

 Why is it True by default? Do we have statistics showing that Python
 gets more use in summer?

 Because for some reason both me and Stuart Bishop thought it should be, but
 at least in my case I don't have any actual good reason why. Checking with
 how pytz does this shows that pytz in fact defaults to False, so I think
 the default should be False.

Here, too, I think that sticking with pytz's default would be a good idea.

Cheers,

Dirkjan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

2012-12-12 Thread Paul Moore

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 environment without internet access? Or with
a firewall blocking Python's requests and returning an error page
without warning (so the updater just sees incorrect data)? What about
corporate environments that want to control the rollout of updates? (I
can't imagine that in practice, but certainly companies do it for
Java). Most Windows updaters use the official Windows APIs so that
they work properly with odd cases like ISA proxies taking credentials
from the Windows user login. Python's stdlib doesn't support that type
of thing.

I'm -1 on auto-updating because it's too easy to produce a nearly
right solution that doesn't work in highly-controlled (e.g.,
corporate) environments. And a correct solution would be hard to
support with python-dev's level of Windows expertise.

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

2012-12-12 Thread Antoine Pitrou

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 people are so obsessed about updating the timezone
database. Really, this is not worse than having a vulnerable OpenSSL
linked with your Python executable. Purity does not bring any
advantage here.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

2012-12-12 Thread Guido van Rossum

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
 update the info. This is what Java itself is doing anyway.

 I don't get why people are so obsessed about updating the timezone
 database. Really, this is not worse than having a vulnerable OpenSSL
 linked with your Python executable. Purity does not bring any
 advantage here.

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 that local news sources tend to
track :-) and they can update their software when stuff they use
starts getting the time wrong. Obviously sysadmins responsible for
large numbers of users can make this into a routine, and ditto people
who run services. But these folks are professionals and are good at
automating tasks like this.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

2012-12-12 Thread Steve Dower

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 that do in an environment without internet access? Or with a
 firewall blocking Python's requests and returning an error page without
 warning (so the updater just sees incorrect data)? What about corporate
 environments that want to control the rollout of updates? (I can't imagine
 that in practice, but certainly companies do it for Java). Most Windows
 updaters use the official Windows APIs so that they work properly with
 odd cases like ISA proxies taking credentials from the Windows user login.
 Python's stdlib doesn't support that type of thing.
 
 I'm -1 on auto-updating because it's too easy to produce a nearly right
 solution that doesn't work in highly-controlled (e.g.,
 corporate) environments. And a correct solution would be hard to support
 with python-dev's level of Windows expertise.

And what about embedded installations of Python, such as in TortoiseHg? And all 
the people (such as myself) who disable updaters that they don't like or didn't 
expect?

The correct solution on Windows may be to use a static database for 
historical dates and the information in the registry for current and future 
dates. The registry is updated through Windows Update, which is at least as 
reliable as anything Python could do. (I'm not sure exactly what the state of 
updates to older versions is like, but I'd assume WinXP still gets timezone 
updates and Win2K doesn't.)

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. Unfortunately it doesn't look like there's 
enough overlap to allow an automated mapping.

That said, it is incredibly easy to convert between UTC and local 
(http://msdn.microsoft.com/en-us/library/ms724949.aspx), even for dates in the 
past or future when the information is available. It's just that timezones 
other than the user's preference are difficult.

Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

2012-12-12 Thread Éric Araujo

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 datetime.timezone
 
 How well does hg handle files renames? The datetime module could be
 converted to a package.

Quite well.  It’s easy to rename datetime.py to datetime/__init__py, and
subsequent fixes in 3.3’s datetime.py will be merged into
datetime/__init__.py by Mercurial’s merge subsystem.

Cheers
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

2012-12-12 Thread Greg Ewing


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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

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 inclusion, start changing the API.

But this bit of the API is there only as a hack, because stdlib does
not support is_dst. We are changing that. Hence those extra functions
are no longer needed.

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

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 from zoneinfo. Unfortunately it doesn't look like there's 
 enough overlap to allow an automated mapping.

No, but the Unicode consortium (I think) is keeping a mapping updated
manually. I'm using that in tzlocal, to figure out the local timezone
of the computer on Windows.
However, I think that mixing and matching timezone data in this way
from the two systems are likely to be full of pitfalls edge-cases and
complexities I do not dare even think seriously about. There will
probably be *less* errors by just keeping an old timezone database
around. Besides, what it they don't run Windows update? Then the data
still is outdated?

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

2012-12-12 Thread Christian Tismer

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, Dec 11, 2012 at 8:07 AM, Antoine Pitrousolip...@pitrou.net
wrote:

Le Tue, 11 Dec 2012 16:23:37 +0100,
Lennart Regebrorege...@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.

* ``tzinfo.utcoffset(self, dt, is_dst=True)``

* ``tzinfo.dst(self, dt, is_dst=True)``

* ``tzinfo.tzname(self, dt, is_dst=True)``

The ``is_dst`` parameter can be ``True`` (default), ``False``, or
``None``.

``True`` will specify that the given datetime should be interpreted
as happening during daylight savings time, ie that the time

specified

is before the change from DST.

Why is it True by default? Do we have statistics showing that Python
gets more use in summer?

My question exactly.

Summer in the USA, at least, is 238 days in 2012, while Winter into 2013 is 
only 126 days:

import datetime
datetime.date(2012, 11, 4) - datetime.date(2012, 3, 11)

datetime.timedelta(238)

datetime.date(2013, 3, 10) - datetime.date(2012, 11, 4)

datetime.timedelta(126)

Very funny, but that can't be the real reason. *Most* datetime values
aren't ambiguous, so in those cases the parameter should be ignored,
right? There's only one hour per year where you need to specify it
(two, if we want to artificially assign a meaning to values falling
the impossible hour). And during those times it's equally likely that
you meant either of the possibilities. I think the meaning of the
parameter must be clarified, perhaps as follows:

- ignored except during the ambiguous hour and during the impossible hour
- during the ambiguous or impossible hour:
   - if True, prefer/pretend DST
   - if False, prefer/pretend non-DST
   - if None, raise an error

Here I'd prefer the default to be None if I had to do it over again,
but given that the current behavior is one of the first two (which
one?) we probably can't do that. Still, it's slightly confusing that
passing None is not the same as omitting the parameter altogether --
there aren't many APIs that explicitly support passing None but don't
use it as the default (though there probably are some precedents).
Maybe requesting an error should be done through some other special
value, and None should be the same as omitted and the same as the old
behavior? But where would the special value come from? It should be
made as easy as possible to do the right thing (i.e. raise an
error). Or maybe have a separate Boolean flag to request an error?

I see an issue here that makes me a little uncomfortable:
Having a default that makes code work all year but raises an error during
the impossible hour could be problematic in critical code.
Can we make this more explicit by forcing the users to decide?

I like the idea of the extra boolean flag here, because it will be 
explicitly

visible that this code intentionally creates an exception.
Or even not a flag, but the exception to be raised, or a callable to
handle this case?

Sloppy coding can be dangerous. So maybe the warning module could be
helpful as well: If None is passed and no explicit flag/exception/callable
given, bother the user with a warning message ;-)

cheers - chris

--
Christian Tismer :^)mailto:tis...@stackless.com
Software Consulting  : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 :*Starship*http://starship.python.net/
14482 Potsdam: PGP key -http://pgp.uni-mainz.de
phone +49 173 24 18 776  fax +49 (30) 700143-0023
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?http://www.stackless.com/

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

2012-12-12 Thread Terry Reedy


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 that local news sources tend to
track :-) and they can update their software when stuff they use
starts getting the time wrong. Obviously sysadmins responsible for
large numbers of users can make this into a routine, and ditto people
who run services. But these folks are professionals and are good at
automating tasks like this.


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. 
I would like every installer, including for bug fix releases, to update 
it. This should be sufficient for 99% of Windows users. As Guido says 
above, the docs should tell the other 1% how to update it explicitly.



--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

2012-12-12 Thread Terry Reedy


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.


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,


And gratuitous, to me. I don't generally like 'get' prefixes anyway.


but changing pytz.timezone(foo) to timezone.timezone(foo) is really
significantly easier than renaming it to timezone.get_timezone(foo).

If we keep all of the API intact you could do

 try:
 import pytz as timezone
 except ImportError:
 import timezone

Which would make porting quicker, that's true, but do we really want to keep
unecessary API's around forever? Isn't it better to minimize the noise from
the start?


While the module that was the basis for the ipaddress module was 
released on PyPI and its api developed however it did, the API was 
worked over quite a bit before the addition of ipaddress. So I agree 
that the current api can be revised before being more-or-less frozen in 
the stdlib.



It also seems relatively painless to keep localize() and normalize()
functions around for easy porting.


Sure, but you then have two ways of doing the same thing, which I think we
should avoid.


I agree that this is precisely the time to remove cruft (if indeed it is 
such).


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

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 location for zoneinfo files. And do we really want to install
python-specific files outside the Python tree?


//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

2012-12-12 Thread MRAB


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 would that be installed? There is no
standard location for zoneinfo files. And do we really want to install
python-specific files outside the Python tree?


Python version x.y is installed into, say, C:\Pythonxy, so perhaps a
good place would be, say, C:\Python.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

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, including ones included with other apps.


 That would be nice, but where would that be installed? There is no
 standard location for zoneinfo files. And do we really want to install
 python-specific files outside the Python tree?

 Python version x.y is installed into, say, C:\Pythonxy, so perhaps a
 good place would be, say, C:\Python.

C:\ProgramData\Python
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

2012-12-12 Thread Terry Reedy


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 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 zoneinfo files. And do we really want to install
python-specific files outside the Python tree?


There is no 'Python tree' on windows. Rather, there is a separate tree 
for each version, located where the user directs.


Windows used to have a %APPDATA% directory variable. Not sure about Win 
7, let alone 8. Martin and others should know better.


Or ask the user where to put it. I know where I would choose, and it 
would not be on my C drive. Un-installers would not delete (unless a 
reference count were kept and were decremented to 0).



Python version x.y is installed into, say, C:\Pythonxy, so perhaps a
good place would be, say, C:\Python.


C:\ProgramData\Python


Making a new top-level directory without asking is obnoxious.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

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:


 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 zoneinfo files. And do we really want to install
 python-specific files outside the Python tree?


 There is no 'Python tree' on windows. Rather, there is a separate tree
for each version, located where the user directs.

 Windows used to have a %APPDATA% directory variable. Not sure about Win
7, let alone 8. Martin and others should know better.

 Or ask the user where to put it. I know where I would choose, and it
would not be on my C drive. Un-installers would not delete (unless a
reference count were kept and were decremented to 0).


 Python version x.y is installed into, say, C:\Pythonxy, so perhaps a
 good place would be, say, C:\Python.


 C:\ProgramData\Python


 Making a new top-level directory without asking is obnoxious.

See
http://stackoverflow.com/questions/9518890/what-is-the-significance-programdata-in-windows
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

2012-12-12 Thread Glenn Linderman


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-significance-programdata-in-windows




___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

2012-12-12 Thread Janzert


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 FOLDERID_ProgramData. The actual on disk location 
for this has changed over windows versions. As noted below in the SO 
link given:


Note that this documentation refers to the typical path as per older 
versions of Windows. In modern versions of Windows it is located in 
%SystemDrive%\ProgramData.





 Making a new top-level directory without asking is obnoxious.

See
http://stackoverflow.com/questions/9518890/what-is-the-significance-programdata-in-windows








___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

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 rather confusing though. :/ It's referring to
 KNOWNFOLDERID constant FOLDERID_ProgramData. The actual on disk location for
 this has changed over windows versions. As noted below in the SO link given:

 Note that this documentation refers to the typical path as per older
 versions of Windows. In modern versions of Windows it is located in
 %SystemDrive%\ProgramData.

Correct.

Anyway, on with the actual timezone stuff...
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

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 non-standard
locations. While installers for software with Python don't want their
users to be asked, so they'll install it in the standard location,
overriding the managers preferred, updated custom location with the
standard location with a database that is probably not updated.

So I think that asking is not an option at all. It either goes in
%PROGRAMDATA%\Python\zoneinfo or it's not shared at all.

 I know where I would choose, and it would
 not be on my C drive. Un-installers would not delete (unless a reference
 count were kept and were decremented to 0).

True, and that's annoying when those counters go wrong.

All in all I would say I would prefer to install this per Python.

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

2012-12-12 Thread Glenn Linderman

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. :/

c:\Documents and Settings\AllUsers\Application Data (which I knew from
XP, and I think 2000, not sure I remember NT)

In Vista.0, Vista.1, and Vista.2, I guess it is moved to
C:\users\AllUsers\AppData\Roaming (typically).

Neither of those would result in C:\ProgramData\Python.

It's referring to KNOWNFOLDERID constant FOLDERID_ProgramData. The
actual on disk location for this has changed over windows versions. As
noted below in the SO link given:

Note that this documentation refers to the typical path as per older
versions of Windows. In modern versions of Windows it is located in
%SystemDrive%\ProgramData.

Making a new top-level directory without asking is obnoxious.

See
http://stackoverflow.com/questions/9518890/what-is-the-significance-programdata-in-windows

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

2012-12-12 Thread Janzert

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 actually does; it is rather confusing though. :/

c:\Documents and Settings\AllUsers\Application Data (which I knew from
XP, and I think 2000, not sure I remember NT)

In Vista.0, Vista.1, and Vista.2, I guess it is moved to
C:\users\AllUsers\AppData\Roaming (typically).

Neither of those would result in C:\ProgramData\Python.

The SO answer links to the KNOWNFOLDERID docs; the relevant entry
specifically is at

http://msdn.microsoft.com/en-us/library/windows/desktop/dd378457.aspx#FOLDERID_ProgramData

which gives the default path as,

%ALLUSERSPROFILE% (%ProgramData%, %SystemDrive%\ProgramData)

checking on my local windows 7 install gives:

C:\echo %ALLUSERSPROFILE%
C:\ProgramData

C:\echo %ProgramData%
C:\ProgramData

It's referring to KNOWNFOLDERID constant FOLDERID_ProgramData. The
actual on disk location for this has changed over windows versions. As
noted below in the SO link given:

Note that this documentation refers to the typical path as per older
versions of Windows. In modern versions of Windows it is located in
%SystemDrive%\ProgramData.

Making a new top-level directory without asking is obnoxious.

See
http://stackoverflow.com/questions/9518890/what-is-the-significance-programdata-in-windows

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Draft PEP for time zone support.

2012-12-11 Thread Lennart Regebro

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 Track
Content-Type: text/x-rst
Created: 11-Dec-2012
Post-History: 11-Dec-2012

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.


Proposal


Concrete time zone support
--

The time zone support in Python has no concrete implementation in the
standard library, only a tzinfo baseclass, and since Python 3.2, one concrete
time zone: UTC. To properly support time zones you need to include a database
over all time zones, both current and historical, including daylight saving
changes. But such information changes frequently, so even if we include the
last information in a Python release, that information would be outdated just
a few months later.

Timezone support has therefore only been available through two third-party
modules, ``pytz`` and ``dateutil``, both who include and wrap the zoneinfo
database. This database, also called tz or The Olsen database, is the
de-facto standard time zone database over time zones, and it is included in
most variants of Unix operating systems, including OS X.

This gives us the opportunity to include only the code that supports the
zoneinfo data in the standard library, but by default use the operating
systems copy of the data, which typically will be kept updated by the
updating mechanism of the operating system or distribution.

For those who have an operating system that does not include the tz database,
for example Windows, a distribution containing the latest tz database should
also be available at the Python Package Index, so it can be easily installed
with the Python packaging tools such as ``easy_install`` or ``pip``. This
could also be done on Unices that are no longer recieving updates and
therefore has an outdated database.

With such a mechanism Python would have full time zone support in the
standard library on most platforms, and a simple package installation would
provide time zone support on those platforms where the tz database isn't
included, such as Windows.

The time zone support will be implemented by a new module called `timezone``,
based on Stuart Bishop's ``pytz`` module.


Getting the local time zone
---

On Unix there is no standard way of finding the name of the time zone that is
being used. All the information that is available is the time zone
abbreviations, such as ``EST`` and ``PDT``, but many of those abbreviations
are ambigious and therefore you can't rely on them to figure out which time
zone you are located in.

There is however a standard for finding the compiled time zone information
since it's located in ``/etc/localtime``. Therefore it is possible to create
a local time zone object with the correct time zone information even though
you don't know the name of the time zone. A function in ``datetime`` should
be provided to return the local time zone.

The support for this will be made by integrating Lennart Regebro's
``tzlocal`` module into the new ``timezone`` module.


Ambiguous times
---

When changing over from daylight savings time the clock is turned back one
hour. This means that the times during that hour happens twice, once without
DST and then once with DST. Similarily, when changing to daylight savings
time, one hour goes missing.

The current time zone API can not differentiating between the two ambiguous
times during a change from DST. For example, in Stockholm the time of
2012-11-28 02:00:00 happens twice, both at UTC 2012-11-28 00:00:00 and also
at 2012-11-28 01:00:00.

The current time zone API can not disambiguate this and therefore it's
unclear which time should be returned::

# This could be either 00:00 or 01:00 UTC:
 dt = datetime(2012, 11, 28, 2, 0, tzinfo=timezone('Europe/Stockholm'))
# But we can not specify which:
 dt.astimezone(timezone('UTC'))
datetime.datetime(2012, 11, 28, 1, 0, tzinfo=UTC)

``pytz`` solved this problem by adding ``is_dst`` parameters to several
methods of the tzinfo objects to make it possible to disambiguate times when
this is desired.

This PEP proposes to add these ``is_dst`` parameters to the relevant methods
of the ``datetime`` API, and therefore add this functionality directly to
``datetime``. This is likely the hardest part of this PEP as this
involves updating
the


Implementation API
==

The new ``timezone``-module
---

The public API of the new ``timezone``-module contains one new class, one new
function and one new exception.

* New class: ``DstTzInfo``

  This class provides a concrete

Re: [Python-Dev] Draft PEP for time zone support.

2012-12-11 Thread Dirkjan Ochtman

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 new timezone library.

 * New function :``get_timezone(name=None, db=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.
   If not given, the local timezone will be looked up. If an invalid zone name
   are given, or the local timezone can not be retrieved, the function raises
   `UnknownTimeZoneError`.

   The function also takes an optional path to the location of the zoneinfo
   database which should be used. If not specified, the function will check if
   the `timezonedata` module is installed, and then use that location
 or otherwise
   use the database in ``/usr/share/zoneinfo``.

   If no database is found an ``UnknownTimeZoneError`` or subclass thereof will
   be raised with a message explaining that no zoneinfo database can be found,
   but that you can install one with the ``timezonedata`` package.

It seems like calling get_timezone() with an unknown timezone should
just throw ValueError, not necessarily some custom Exception? It would
probably be a good idea to have a different exception for the case of
no database available.

 Differences from the ``pytz`` API
 =

 * ``pytz`` has the functions ``localize()`` and ``normalize()`` to work
   around that ``tzinfo`` doesn't have is_dst. When ``is_dst`` is
   implemented directly in ``datetime.tzinfo`` they are no longer needed.

 * The ``pytz`` method ``timezone()`` is instead called
 ``get_timezone()`` for clarity.

 * ``get_timezone()``  will return the local time zone if called
 without parameters.

 * The class ``pytz.StaticTzInfo`` is there to provide the ``is_dst``
 support for static
   timezones. When ``is_dst`` support is included in
 ``datetime.tzinfo`` it is no longer needed.

This feels a bit superfluous. Why not keep a bit more of the pytz API
to make porting easy? The pytz API has proven itself in the wild, so I
don't see much point in renaming for clarity. It also seems
relatively painless to keep localize() and normalize() functions
around for easy porting.

 Discussion
 ==

 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 installation no longer would be
 needed on Windows. On the other hand, that would mean that many using Windows
 would not be aware that the database quickly becomes outdated and would not
 keep it updated.

I still submit that it's pretty much just as easy to forget to update
the database whether it's been installed by hand zero or one times, so
I don't find your argument convincing. I don't mind the result much,
though.

Looking forward to have timezone support in the stdlib!

Cheers,

Dirkjan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

2012-12-11 Thread Paul Moore

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 installation no longer would be
 needed on Windows. On the other hand, that would mean that many using Windows
 would not be aware that the database quickly becomes outdated and would not
 keep it updated.

 I still submit that it's pretty much just as easy to forget to update
 the database whether it's been installed by hand zero or one times, so
 I don't find your argument convincing. I don't mind the result much,
 though.

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 not necessarily the
accuracy of that data).

If the base Windows installer does not include timezone data, then the
documentation should note this and offer advice on how to write code
that degrades gracefully without timezones.

If the base installer *does* include timezone data, of course, there
should be a documented mechanism for updating it (we don't want magic
like the old xml package used, I assume).

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

2012-12-11 Thread Brian Curtin

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 installer should include the data
 package. This would mean that an explicit installation no longer would be
 needed on Windows. On the other hand, that would mean that many using 
 Windows
 would not be aware that the database quickly becomes outdated and would not
 keep it updated.

 I still submit that it's pretty much just as easy to forget to update
 the database whether it's been installed by hand zero or one times, so
 I don't find your argument convincing. I don't mind the result much,
 though.

 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 not necessarily the
 accuracy of that data).

 If the base Windows installer does not include timezone data, then the
 documentation should note this and offer advice on how to write code
 that degrades gracefully without timezones.

 If the base installer *does* include timezone data, of course, there
 should be a documented mechanism for updating it (we don't want magic
 like the old xml package used, I assume).

I think we should try to get the data into the base installer and then
include a small updater, perhaps putting it in a Windows scheduled
task and checking PyPI periodically for newer versions. If a new one
comes up, prompt if the user wants it.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

2012-12-11 Thread Antoine Pitrou

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.
 
 * ``tzinfo.utcoffset(self, dt, is_dst=True)``
 
 * ``tzinfo.dst(self, dt, is_dst=True)``
 
 * ``tzinfo.tzname(self, dt, is_dst=True)``
 
 The ``is_dst`` parameter can be ``True`` (default), ``False``, or
 ``None``.
 
 ``True`` will specify that the given datetime should be interpreted
 as happening during daylight savings time, ie that the time specified
 is before the change from DST.

Why is it True by default? Do we have statistics showing that Python
gets more use in summer?

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

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, committed
and pushed.

Thanks Lennart!
-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

2012-12-11 Thread Donald Stufft

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 https://raw.github.com/regebro/tz-pep/master/pep-04tz.txt 
 
  PEP: 4??
 
 I've assigned this PEP 431, reformatted a few extra wide paragraphs, committed
 and pushed.
 
 Thanks Lennart!
 -Barry
 
 ___
 Python-Dev mailing list
 Python-Dev@python.org (mailto:Python-Dev@python.org)
 http://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe: 
 http://mail.python.org/mailman/options/python-dev/donald.stufft%40gmail.com
 
 


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

2012-12-11 Thread Brandon W Maister

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:
 
 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,
 committed
 and pushed.

 Thanks Lennart!
 -Barry

 ___
 Python-Dev mailing list
 Python-Dev@python.org
 http://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe:
 http://mail.python.org/mailman/options/python-dev/quodlibetor%40gmail.com


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

2012-12-11 Thread Guido van Rossum

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`
 methods to handle time ambiguity during DST changeovers.

 * ``tzinfo.utcoffset(self, dt, is_dst=True)``

 * ``tzinfo.dst(self, dt, is_dst=True)``

 * ``tzinfo.tzname(self, dt, is_dst=True)``

 The ``is_dst`` parameter can be ``True`` (default), ``False``, or
 ``None``.

 ``True`` will specify that the given datetime should be interpreted
 as happening during daylight savings time, ie that the time specified
 is before the change from DST.

 Why is it True by default? Do we have statistics showing that Python
 gets more use in summer?

My question exactly.

The rest sounds good -- definitely use the system tz database on Unixy
systems, pre-install on Windows and make updating easy. Some
bikeshedding about static I don't really understand, so I'll leave to
others.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

2012-12-11 Thread Nick Coghlan

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 changes.


Thanks for tackling this one, Lennart.


 Proposal
 

 Concrete time zone support
 --

 The time zone support in Python has no concrete implementation in the
 standard library, only a tzinfo baseclass, and since Python 3.2, one
 concrete
 time zone: UTC.


This isn't quite right - the current concrete timezones support any fixed
offset from UTC, not just UTC itself.
http://docs.python.org/3/library/datetime#timezone-objects

(Although there a couple of bugs in those docs at the moment:
http://bugs.python.org/issue16667)


 The time zone support will be implemented by a new module called
 `timezone``,
 based on Stuart Bishop's ``pytz`` module.


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).


 This PEP proposes to add these ``is_dst`` parameters to the relevant
 methods
 of the ``datetime`` API, and therefore add this functionality directly to
 ``datetime``. This is likely the hardest part of this PEP as this
 involves updating
 the


Missing the end of this sentence...


 The ``timezonedata``-package
 -

 The zoneinfo database will be packaged for easy installation with
 ``easy_install``/``pip``/``buildout``. This package will not install any
 Python code, and will not contain any Python code except that which is
 needed
 for installation.


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 OS (especially if they install it into the system
site packages on a distro that has migrated to Python 3 for system tools).

Such a name would also make it possible to provide *two* packaged
databases, one checked before the OS data (tzdata_override), and one
shipped with Python itself that is used only if the OS doesn't provide the
timezone database (tzdata_fallback). tzdata_fallback would then be updated
to the latest Olsen database for each maintenance release. Cross-platform
applications that wanted more reliably up to date timezone data could then
conditionally depend on tzdata_override for Windows deployments (using the
environment marker support in metadata 1.2+).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

2012-12-11 Thread Robert Brewer

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,
  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.

  * ``tzinfo.utcoffset(self, dt, is_dst=True)``

  * ``tzinfo.dst(self, dt, is_dst=True)``

  * ``tzinfo.tzname(self, dt, is_dst=True)``

  The ``is_dst`` parameter can be ``True`` (default), ``False``, or
  ``None``.

  ``True`` will specify that the given datetime should be interpreted
  as happening during daylight savings time, ie that the time
 specified
  is before the change from DST.

  Why is it True by default? Do we have statistics showing that Python
  gets more use in summer?

 My question exactly.

Summer in the USA, at least, is 238 days in 2012, while Winter into 2013 is 
only 126 days:

 import datetime
 datetime.date(2012, 11, 4) - datetime.date(2012, 3, 11)
datetime.timedelta(238)
 datetime.date(2013, 3, 10) - datetime.date(2012, 11, 4)
datetime.timedelta(126)

Robert Brewer
fuman...@aminus.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

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 add this functionality directly to
``datetime``. This is likely the hardest part of this PEP as this
involves updating
the

Oops, something got cut off there.

The new ``timezone``-module
---

The public API of the new ``timezone``-module contains one new class, one new
function and one new exception.

Why add a new module instead of putting all this into the existing datetime
module, either directly or as a submodule?  Seems like the obvious place to
put it instead of claiming another top-level module name.

* New class: ``DstTzInfo``

  This class provides a concrete implementation of the ``zoneinfo`` base
  class that implements DST support.

Is this a subclass of datetime.tzinfo?

* New function :``get_timezone(name=None, db=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.
  If not given, the local timezone will be looked up. If an invalid zone name
  are given, or the local timezone can not be retrieved, the function raises
  `UnknownTimeZoneError`.

  The function also takes an optional path to the location of the zoneinfo
  database which should be used. If not specified, the function will check if
  the `timezonedata` module is installed, and then use that location or
  otherwise use the database in ``/usr/share/zoneinfo``.

I'm bikeshedding, but can we find a better name than `db` for the second
argument?  Something that makes it obvious we're looking for file system path?

* New Exception: ``UnknownTimeZoneError``

I'd really like to see a TimeZoneError base class from which all these new
exceptions inherit.

A new ``is_dst`` parameter is added to several of the `tzinfo` methods to
handle time ambiguity during DST changeovers.

* ``tzinfo.utcoffset(self, dt, is_dst=True)``

I lied a little bit - I did skim the other messages, so I'll reserve comment
on the default value of is_dst for follow ups.

* ``AmbiguousTimeError``

* ``NonExistentTimeError``

I'm not positive we need separate exceptions here, but I guess it can't hurt,
and with the base class idea above, we can catch both either explicitly, or by
catching the base class.

The ``timezonedata``-package
-

Just to be clear, this doesn't expose any new modules, right?

Cheers,
-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

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 not necessarily the
accuracy of that data).

One other thing that the PEP should describe is what happens on a distro that
has timezone data, but which you also pip install the PyPI tzdata package.
Which one wins?  Is there a way to control it, other than providing an
explicit path?  Is there a way to uninstall the PyPI package?  Does the API
need to provide a method which tells you where the database it is using by
default lives?

Cheers,
-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

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 raise a ``NonExistentTimeError``
if a time is specified during the missing time in a change to DST.

I think None should be the default.

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.

2012-12-11 Thread Nick Coghlan

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`` exception if the time
 specified
 was during a DST change over. It will also raise a
 ``NonExistentTimeError``
 if a time is specified during the missing time in a change to DST.

 I think None should be the default.


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 argument form of these calls continues to
behave the same in 3.4 as it does in 3.3, emitting a DeprecationWarning to
say that the default behaviour is going to change in 3.5 (so the *actual*
default would be sentinel value, in order to tell the difference between an
explicit True being passed and relying on the default behaviour).


Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Draft PEP for time zone support.