[Python-Dev] Draft PEP for time zone support.
14 views
Skip to first unread message
Lennart Regebro
Dec 11, 2012, 10:23:37 AM12/11/12
to Python Developers, pe...@python.org
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 <reg...@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 implementation of the ``zoneinfo`` base
class that implements DST support.
* 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.
* New Exception: ``UnknownTimeZoneError``
This exception is raised when giving a time zone specification that
can't be found::
>>> datetime.Timezone('Europe/New_York')
Traceback (most recent call last):
...
UnknownTimeZoneError: There is no time zone called 'Europe/New_York'
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.
``False`` will specify that the given datetime should be interpreted as not
happening during daylight savings time, ie that the time specified is after
the change from DST.
``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.
There are also two new exceptions:
* ``AmbiguousTimeError``
This exception is raised when giving a datetime specification that
are ambigious
while setting ``is_dst`` to None::
>>> datetime(2012, 11, 28, 2, 0,
tzinfo=timezone('Europe/Stockholm'), is_dst=None)
>>>
Traceback (most recent call last):
...
AmbiguousTimeError: 2012-10-28 02:00:00 is ambiguous in time zone
Europe/Stockholm
* ``NonExistentTimeError``
This exception is raised when giving a datetime specification that
are ambigious
while setting ``is_dst`` to None::
>>> datetime(2012, 3, 25, 2, 0,
tzinfo=timezone('Europe/Stockholm'), is_dst=None)
>>>
Traceback (most recent call last):
...
NonExistentTimeError: 2012-03-25 02:00:00 does not exist in time
zone Europe/Stockholm
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.
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.
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.
Resources
=========
* http://pytz.sourceforge.net/
* http://pypi.python.org/pypi/tzlocal
* http://pypi.python.org/pypi/python-dateutil
Copyright
=========
This document has been placed in the public domain.
_______________________________________________
Python-Dev mailing list
Pytho...@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/dev-python%2Bgarchive-30976%40googlegroups.com
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 <reg...@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 implementation of the ``zoneinfo`` base
class that implements DST support.
* 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.
* New Exception: ``UnknownTimeZoneError``
This exception is raised when giving a time zone specification that
can't be found::
>>> datetime.Timezone('Europe/New_York')
Traceback (most recent call last):
...
UnknownTimeZoneError: There is no time zone called 'Europe/New_York'
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.
``False`` will specify that the given datetime should be interpreted as not
happening during daylight savings time, ie that the time specified is after
the change from DST.
``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.
There are also two new exceptions:
* ``AmbiguousTimeError``
This exception is raised when giving a datetime specification that
are ambigious
while setting ``is_dst`` to None::
>>> datetime(2012, 11, 28, 2, 0,
tzinfo=timezone('Europe/Stockholm'), is_dst=None)
>>>
Traceback (most recent call last):
...
AmbiguousTimeError: 2012-10-28 02:00:00 is ambiguous in time zone
Europe/Stockholm
* ``NonExistentTimeError``
This exception is raised when giving a datetime specification that
are ambigious
while setting ``is_dst`` to None::
>>> datetime(2012, 3, 25, 2, 0,
tzinfo=timezone('Europe/Stockholm'), is_dst=None)
>>>
Traceback (most recent call last):
...
NonExistentTimeError: 2012-03-25 02:00:00 does not exist in time
zone Europe/Stockholm
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.
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.
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.
Resources
=========
* http://pytz.sourceforge.net/
* http://pypi.python.org/pypi/tzlocal
* http://pypi.python.org/pypi/python-dateutil
Copyright
=========
This document has been placed in the public domain.
_______________________________________________
Python-Dev mailing list
Pytho...@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/dev-python%2Bgarchive-30976%40googlegroups.com
Dirkjan Ochtman
Dec 11, 2012, 10:39:33 AM12/11/12
to Lennart Regebro, Python Developers
On Tue, Dec 11, 2012 at 4:23 PM, Lennart Regebro <reg...@gmail.com> wrote:
> Proposal
> ========
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
> 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
> The time zone support will be implemented by a new module called `timezone``,
> based on Stuart Bishop's ``pytz`` module.
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.
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.
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.
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
Paul Moore
Dec 11, 2012, 10:48:18 AM12/11/12
to Dirkjan Ochtman, Python Developers
On 11 December 2012 15:39, Dirkjan Ochtman <dir...@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
>> 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.
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.
Brian Curtin
Dec 11, 2012, 10:58:12 AM12/11/12
to Paul Moore, Python Developers
On Tue, Dec 11, 2012 at 9:48 AM, Paul Moore <p.f....@gmail.com> wrote:
> On 11 December 2012 15:39, Dirkjan Ochtman <dir...@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
> On 11 December 2012 15:39, Dirkjan Ochtman <dir...@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).
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.
Antoine Pitrou
Dec 11, 2012, 11:07:55 AM12/11/12
to pytho...@python.org
Le Tue, 11 Dec 2012 16:23:37 +0100,
Lennart Regebro <reg...@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.
Lennart Regebro <reg...@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.
Barry Warsaw
Dec 11, 2012, 3:31:37 PM12/11/12
to pytho...@python.org
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?!
>This PEP is also available on github:
>
>https://github.com/regebro/tz-pep/blob/master/pep-04tz.txt
>PEP: 4??
I've assigned this PEP 431, reformatted a few extra wide paragraphs, committed
and pushed.
Thanks Lennart!
-Barry
Donald Stufft
Dec 11, 2012, 3:34:45 PM12/11/12
to Barry Warsaw, pytho...@python.org
On Tuesday, December 11, 2012 at 3:31 PM, Barry Warsaw wrote:
On Dec 11, 2012, at 04:23 PM, Lennart Regebro wrote:
wget returns some html gobbledygook. Why-oh-why github?!'
PEP: 4??I've assigned this PEP 431, reformatted a few extra wide paragraphs, committedand pushed.Thanks Lennart!-Barry
_______________________________________________Python-Dev mailing list
Brandon W Maister
Dec 11, 2012, 3:37:01 PM12/11/12
to Barry Warsaw, python-dev
Barry you want github raw: https://raw.github.com/regebro/tz-pep/master/pep-04tz.txt
_______________________________________________
Python-Dev mailing list
Pytho...@python.org
http://mail.python.org/mailman/listinfo/python-dev
Guido van Rossum
Dec 11, 2012, 7:11:11 PM12/11/12
to Antoine Pitrou, pytho...@python.org
On Tue, Dec 11, 2012 at 8:07 AM, Antoine Pitrou <soli...@pitrou.net> wrote:
> Le Tue, 11 Dec 2012 16:23:37 +0100,
> Lennart Regebro <reg...@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.
> Le Tue, 11 Dec 2012 16:23:37 +0100,
> Lennart Regebro <reg...@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?
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)
Nick Coghlan
Dec 11, 2012, 7:58:12 PM12/11/12
to Lennart Regebro, pe...@python.org, Python Developers
On Wed, Dec 12, 2012 at 1:23 AM, Lennart Regebro <reg...@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 | ncog...@gmail.com | Brisbane, Australia
Robert Brewer
Dec 11, 2012, 8:11:20 PM12/11/12
to Guido van Rossum, Antoine Pitrou, pytho...@python.org
Guido van Rossum wrote:
> Sent: Tuesday, December 11, 2012 4:11 PM
> To: Antoine Pitrou
> Cc: pytho...@python.org
> Subject: Re: [Python-Dev] Draft PEP for time zone support.
>>> 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
fuma...@aminus.org
> Sent: Tuesday, December 11, 2012 4:11 PM
> To: Antoine Pitrou
> Cc: pytho...@python.org
> Subject: Re: [Python-Dev] Draft PEP for time zone support.
>
> On Tue, Dec 11, 2012 at 8:07 AM, Antoine Pitrou <soli...@pitrou.net>
> wrote:
> > Le Tue, 11 Dec 2012 16:23:37 +0100,
> > Lennart Regebro <reg...@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:
> On Tue, Dec 11, 2012 at 8:07 AM, Antoine Pitrou <soli...@pitrou.net>
> wrote:
> > Le Tue, 11 Dec 2012 16:23:37 +0100,
> > Lennart Regebro <reg...@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.
>>> 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
fuma...@aminus.org
Barry Warsaw
Dec 11, 2012, 9:50:49 PM12/11/12
to pytho...@python.org
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:
>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
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.
>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
>The new ``timezone``-module
>---------------------------
>
>The public API of the new ``timezone``-module contains one new class, one new
>function and one new exception.
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.
>* 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``.
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)``
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
Barry Warsaw
Dec 11, 2012, 9:54:21 PM12/11/12
to pytho...@python.org
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
>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).
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
Barry Warsaw
Dec 11, 2012, 9:59:24 PM12/11/12
to pytho...@python.org
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 you want github raw:
>https://raw.github.com/regebro/tz-pep/master/pep-04tz.txt
-Barry
Barry Warsaw
Dec 11, 2012, 9:57:24 PM12/11/12
to pytho...@python.org
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.
>I've assigned this PEP 431, reformatted a few extra wide paragraphs, committed
>and pushed.
-Barry
Barry Warsaw
Dec 11, 2012, 9:58:49 PM12/11/12
to pytho...@python.org
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.
>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.
>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.
-Barry
Nick Coghlan
Dec 11, 2012, 10:14:23 PM12/11/12
to Barry Warsaw, pytho...@python.org
Barry Warsaw
Dec 11, 2012, 10:19:30 PM12/11/12
to Nick Coghlan, pytho...@python.org
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 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).
+1
>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,
-Barry
Guido van Rossum
Dec 11, 2012, 10:51:50 PM12/11/12
to Barry Warsaw, Nick Coghlan, pytho...@python.org
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 raised instead.
Right.
> 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 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).
>
> +1
Guido van Rossum
Dec 11, 2012, 8:43:59 PM12/11/12
to Robert Brewer, Lennart Regebro, Antoine Pitrou, pytho...@python.org
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?
Paul Moore
Dec 12, 2012, 3:13:16 AM12/12/12
to Nick Coghlan, Python Developers, pe...@python.org
On 12 December 2012 00:58, Nick Coghlan <ncog...@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 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+).
That sounds sensible, EIBTI and all that. It is a lot simpler than
> 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+).
shipping the package and some sort of auto-updater, too.
Paul
Christian Heimes
Dec 12, 2012, 4:53:34 AM12/12/12
to Nick Coghlan, Python Developers, pe...@python.org
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
> 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).
How well does hg handle files renames? The datetime module could be
converted to a package.
> 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).
Lennart Regebro
Dec 12, 2012, 10:56:54 AM12/12/12
to Christian Heimes, Python Developers, Nick Coghlan, pe...@python.org
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 <dir...@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 <soli...@pitrou.net> wrote:
>> The ``is_dst`` parameter can be ``True`` (default), ``False``, or
>> ``None``.
>>
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
_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 <ncog...@gmail.com> 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
this doesn't apply. The cases where you really care which half past two you
meant, or the cases where you want an error when you specify 2012-03-25 02:30
in Europe/Stockholm is exceedingly rare. Most people would not know this can
happen, and therefore they would not handle the errors, but they would not
want the application to fail when it does happen. I think the default
therefore should be True or False.
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 <dir...@ochtman.nl> wrote:
> I wonder if there needs to be something here about how to port from
> pytz to the new timezone library.
> It seems like calling get_timezone() with an unknown timezone should
> just throw ValueError, not necessarily some custom Exception?
> Why not keep a bit more of the pytz API to make porting easy?
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.
should avoid.
On Tue, Dec 11, 2012 at 5:07 PM, Antoine Pitrou <soli...@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
> gets more use in summer?
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.
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?
> I'd really like to see a TimeZoneError base class from which all these new
> exceptions inherit.
>>The ``timezonedata``-package
>>-----------------------------
>
> Just to be clear, this doesn't expose any new modules, right?
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?
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 <ncog...@gmail.com> wrote:
> That's a backwards compatibility risk, though - many applications are likely
> coping just fine with the slightly corrupted time values, but would fall
> 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).
Although explicit is better than implicit, I think this is one case where
> 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).
this doesn't apply. The cases where you really care which half past two you
meant, or the cases where you want an error when you specify 2012-03-25 02:30
in Europe/Stockholm is exceedingly rare. Most people would not know this can
happen, and therefore they would not handle the errors, but they would not
want the application to fail when it does happen. I think the default
therefore should be True or False.
Brian Curtin
Dec 12, 2012, 11:11:15 AM12/12/12
to Lennart Regebro, pe...@python.org, Christian Heimes, Nick Coghlan, Python Developers
On Wed, Dec 12, 2012 at 9:56 AM, Lennart Regebro <reg...@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
> 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.
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.
Dirkjan Ochtman
Dec 12, 2012, 11:21:52 AM12/12/12
to Lennart Regebro, PEP Editors, Christian Heimes, Nick Coghlan, Python Developers
On Wed, Dec 12, 2012 at 4:56 PM, Lennart Regebro <reg...@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
>> 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?
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.
Cheers,
Dirkjan
Paul Moore
Dec 12, 2012, 11:28:23 AM12/12/12
to Brian Curtin, Christian Heimes, Nick Coghlan, Python Developers, pe...@python.org
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
> 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.
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.
Antoine Pitrou
Dec 12, 2012, 11:44:36 AM12/12/12
to pytho...@python.org
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.
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.
Guido van Rossum
Dec 12, 2012, 11:53:49 AM12/12/12
to Antoine Pitrou, pytho...@python.org
On Wed, Dec 12, 2012 at 8:44 AM, Antoine Pitrou <soli...@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
> 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.
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.
Steve Dower
Dec 12, 2012, 11:54:36 AM12/12/12
to Paul Moore, Brian Curtin, pe...@python.org, Christian Heimes, Nick Coghlan, Python Developers
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?
> 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.
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
Éric Araujo
Dec 12, 2012, 12:51:41 PM12/12/12
to pytho...@python.org
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
Greg Ewing
Dec 12, 2012, 2:51:34 PM12/12/12
to pytho...@python.org
> On Tue, Dec 11, 2012 at 8:07 AM, Antoine Pitrou <soli...@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
>
>>Do we have statistics showing that Python
>>gets more use in summer?
active during the warmer seasons...
--
Greg
Lennart Regebro
Dec 12, 2012, 6:08:57 PM12/12/12
to Dirkjan Ochtman, PEP Editors, Christian Heimes, Nick Coghlan, Python Developers
On Wed, Dec 12, 2012 at 5:21 PM, Dirkjan Ochtman <dir...@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
> 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.
not support is_dst. We are changing that. Hence those extra functions
are no longer needed.
//Lennart
Lennart Regebro
Dec 12, 2012, 6:14:12 PM12/12/12
to Steve Dower, Python Developers, Christian Heimes, Nick Coghlan, pe...@python.org
On Wed, Dec 12, 2012 at 5:54 PM, Steve Dower <Steve...@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
> 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.
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
Christian Tismer
Dec 12, 2012, 5:55:30 PM12/12/12
to Guido van Rossum, pytho...@python.org, Antoine Pitrou
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/
Terry Reedy
Dec 12, 2012, 6:23:37 PM12/12/12
to pytho...@python.org
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
> 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.
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
Terry Reedy
Dec 12, 2012, 6:30:46 PM12/12/12
to pytho...@python.org
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.
>> 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?
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.
such).
--
Terry Jan Reedy
Lennart Regebro
Dec 12, 2012, 6:33:13 PM12/12/12
to Terry Reedy, pytho...@python.org
On Thu, Dec 13, 2012 at 12:23 AM, Terry Reedy <tjr...@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
> 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.
standard location for zoneinfo files. And do we really want to install
python-specific files outside the Python tree?
//Lennart
MRAB
Dec 12, 2012, 7:10:06 PM12/12/12
to python-dev
On 2012-12-12 23:33, Lennart Regebro wrote:
> On Thu, Dec 13, 2012 at 12:23 AM, Terry Reedy <tjr...@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
> On Thu, Dec 13, 2012 at 12:23 AM, Terry Reedy <tjr...@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?
>
good place would be, say, C:\Python.
Brian Curtin
Dec 12, 2012, 7:27:06 PM12/12/12
to python-dev
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 <tjr...@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
> On 2012-12-12 23:33, Lennart Regebro wrote:
>>
>> On Thu, Dec 13, 2012 at 12:23 AM, Terry Reedy <tjr...@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.
Terry Reedy
Dec 12, 2012, 8:24:04 PM12/12/12
to pytho...@python.org
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 <tjr...@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
> 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 <tjr...@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?
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
--
Terry Jan Reedy
Brian Curtin
Dec 12, 2012, 8:36:15 PM12/12/12
to Terry Reedy, Python-Dev
On Dec 12, 2012 7:24 PM, "Terry Reedy" <tjr...@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 <tjr...@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
Glenn Linderman
Dec 12, 2012, 8:43:20 PM12/12/12
to pytho...@python.org
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.
Janzert
Dec 12, 2012, 9:10:46 PM12/12/12
to pytho...@python.org
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
> 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.
>
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
>>
>
>
>
Brian Curtin
Dec 12, 2012, 9:54:23 PM12/12/12
to Janzert, Python-Dev
On Wed, Dec 12, 2012 at 8:10 PM, Janzert <jan...@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.
> 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."
Anyway, on with the actual timezone stuff...
Lennart Regebro
Dec 13, 2012, 1:06:19 AM12/13/12
to Terry Reedy, pytho...@python.org
On Thu, Dec 13, 2012 at 2:24 AM, Terry Reedy <tjr...@udel.edu> wrote:
> Or ask the user where to put it.
If we ask where it should be installed, then we need a registry
> Or ask the user where to put it.
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).
All in all I would say I would prefer to install this per Python.
//Lennart
Glenn Linderman
Dec 13, 2012, 1:39:25 AM12/13/12
to pytho...@python.org
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. :/
I agree with the below. But I have never seen a version of Windows
on which c:\ProgramData was the actual path for
FOLDERID_ProgramData. Can you reference documentation that states
that it was there, for some version? This documentation speaks of:
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.
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.
Janzert
Dec 13, 2012, 2:32:53 AM12/13/12
to pytho...@python.org
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. :/
>
> I agree with the below. But I have never seen a version of Windows on
> which c:\ProgramData was the actual path for FOLDERID_ProgramData. Can
> you reference documentation that states that it was there, for some
> version? This documentation speaks of:
>
> 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
> 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. :/
>
> I agree with the below. But I have never seen a version of Windows on
> which c:\ProgramData was the actual path for FOLDERID_ProgramData. Can
> you reference documentation that states that it was there, for some
> version? This documentation speaks of:
>
> 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.
>
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
>>>>
>
>
>
Terry Reedy
Dec 13, 2012, 3:22:59 AM12/13/12
to pytho...@python.org
On 12/13/2012 1:06 AM, Lennart Regebro wrote:
> On Thu, Dec 13, 2012 at 2:24 AM, Terry Reedy <tjr...@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.
> On Thu, Dec 13, 2012 at 2:24 AM, Terry Reedy <tjr...@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
> 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.
versions. But maybe it only works for dlls.
> All in all I would say I would prefer to install this per Python.
violation of DRY. If if is not too large, it would not hurt to never
delete it.
--
Terry Jan Reedy
Glenn Linderman
Dec 13, 2012, 3:38:01 AM12/13/12
to pytho...@python.org
Interesting. It _did_ say something about data that is not specific
to a user... and yet I overlooked that.
Those environment variable settings are, indeed, on my Win 7 machine, so I have erred and apologize.
That said, the directory C:\ProgramData does NOT exist on my Win 7 machine, so it appears that VERY LITTLE software actually uses that setting. (I have nearly a hundred free and commercial packages installed on this machine. Not that 100 is a large percentage of the available software for Windows, but if the use was common, 100 packages would be likely to contain one that used it, eh?).
Thanks for the education, especially because you had to beat it into my skull!
Those environment variable settings are, indeed, on my Win 7 machine, so I have erred and apologize.
That said, the directory C:\ProgramData does NOT exist on my Win 7 machine, so it appears that VERY LITTLE software actually uses that setting. (I have nearly a hundred free and commercial packages installed on this machine. Not that 100 is a large percentage of the available software for Windows, but if the use was common, 100 packages would be likely to contain one that used it, eh?).
Thanks for the education, especially because you had to beat it into my skull!
Lennart Regebro
Dec 13, 2012, 4:07:34 AM12/13/12
to Terry Reedy, pytho...@python.org
On Thu, Dec 13, 2012 at 9:22 AM, Terry Reedy <tjr...@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, it would not hurt to never delete
> it.
Yes, but this is no different that if you want to keep any library
> 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 not hurt to never delete
> it.
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 updates only for this,
adding to the plethora of update checkers on windows already. You
either keep your Python and it's libraries updated or you do not, I
don't think this is any different, and I think it should have the
exact same mechanisms and functions as all other third-party PyPI
packages.
//Lennart
Antoine Pitrou
Dec 13, 2012, 6:06:18 AM12/13/12
to pytho...@python.org
Le Thu, 13 Dec 2012 10:07:34 +0100,
> On Thu, Dec 13, 2012 at 9:22 AM, Terry Reedy <tjr...@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, it would not hurt to
> > never delete it.
>
> 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 updates only for this,
> adding to the plethora of update checkers on windows already. You
> either keep your Python and it's libraries updated or you do not, I
> don't think this is any different, and I think it should have the
> exact same mechanisms and functions as all other third-party PyPI
> packages.
> > 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 not hurt to
> > never delete it.
>
> 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 updates only for this,
> adding to the plethora of update checkers on windows already. You
> either keep your Python and it's libraries updated or you do not, I
> don't think this is any different, and I think it should have the
> exact same mechanisms and functions as all other third-party PyPI
> packages.
Agreed. This doesn't warrant special-casing.
Regards
Antoine.
Christian Heimes
Dec 13, 2012, 6:34:31 AM12/13/12
to Lennart Regebro, pytho...@python.org
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 updates only for this,
> adding to the plethora of update checkers on windows already. You
> either keep your Python and it's libraries updated or you do not, I
> don't think this is any different, and I think it should have the
> exact same mechanisms and functions as all other third-party PyPI
> packages.
+1
> 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 updates only for this,
> adding to the plethora of update checkers on windows already. You
> either keep your Python and it's libraries updated or you do not, I
> don't think this is any different, and I think it should have the
> exact same mechanisms and functions as all other third-party PyPI
> packages.
This PEP does fine without any auto-updatefeature. Please let Lennart
concentrate on the task at hand. If an auto-update system is still
wanted, it can and should be designed by somebody else as a separate
PEP. IMHO it's not Lennart's obligation to do so.
Christian
Terry Reedy
Dec 13, 2012, 3:45:59 PM12/13/12
to pytho...@python.org
On 12/13/2012 4:07 AM, Lennart Regebro wrote:
> On Thu, Dec 13, 2012 at 9:22 AM, Terry Reedy <tjr...@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, it would not hurt to never delete
>> it.
>
> Yes, but this is no different that if you want to keep any library
> updated over multiple Python versions.
How I do that for my multi-version packages is to put them in a separate
> On Thu, Dec 13, 2012 at 9:22 AM, Terry Reedy <tjr...@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, it would not hurt to never delete
>> it.
>
> Yes, but this is no different that if you want to keep any library
> updated over multiple Python versions.
'python' directory and put python.pth with the path to that directory in
the various site-packages directories. Any change to the *one* copy is
available to all versions and all will operate the same if the code is
truly multi-version. When I installed 3.3, I copied python.pth into its
site-packages and was ready to go.
> And I don't want to invent another installation procedure
> that works for just this,
C:\programdata (which currently does not exist on my machine either).
That would be a new, invented installation procedure.
> or have a little script that checks periodically
> for updates only for this,
> adding to the plethora of update checkers on windows already.
database (available to all Python versions) with each release would be
sufficient for nearly everyone on Windows.
> either keep your Python and it's libraries updated or you do not, I
> exact same mechanisms and functions as all other third-party PyPI
> packages.
When I suggested that users be able to put the database where they want,
> packages.
*just like with any other third-party package PyPI package*, you are the
one who said no, this should be special cased.
The situation is this: most *nixes have or can have one system tz
database. Python code that uses it will give the same answer regardless
of the Python version. Windows apparently does not have such a thing. So
we can
a) not use the tz database in the stdlib because it would not work on
Windows (the defacto current situation);
b) use it but let the functions fail on Windows;
c) install a different version of the database with each Python
installation, that can only be used by that installation, so that
results may depend on the Python version. (This seem to be what you are
now proposing, and if bugfix releases update the data only for that
version, could result in earlier versions giving more accurate answers.);
d) install one database at a time so all Python versions give the same
answer, just as on *nix.
--
Terry Jan Reedy
Lennart Regebro
Dec 14, 2012, 3:31:40 AM12/14/12
to Terry Reedy, pytho...@python.org
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 for Linux distributions may skip this, but that's OK).
2. The timezone module becomes datetime.timezone, meaning datetime.py
is moved to datetime/__init__.py
3. get_timezone() will be just timezone() as no voices was raised to
defend get_timezone()
4. The db parameter in timezone() will be renamed db_path
5. is_dst will default to False
6. The UnknownTimeZoneError exception will be just a ValueError
7. The two errors raised when converting timezones will both inherit
from a base exception.
8. A better name for the timezone data package. "tzdata-override" was
suggested, I prefer "tzdata-update" as it is clearer.
//Lennart
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 for Linux distributions may skip this, but that's OK).
2. The timezone module becomes datetime.timezone, meaning datetime.py
is moved to datetime/__init__.py
3. get_timezone() will be just timezone() as no voices was raised to
defend get_timezone()
4. The db parameter in timezone() will be renamed db_path
5. is_dst will default to False
6. The UnknownTimeZoneError exception will be just a ValueError
7. The two errors raised when converting timezones will both inherit
from a base exception.
8. A better name for the timezone data package. "tzdata-override" was
suggested, I prefer "tzdata-update" as it is clearer.
//Lennart
Christian Heimes
Dec 14, 2012, 6:01:32 AM12/14/12
to Lennart Regebro, pytho...@python.org
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 database stored and under
> 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).
which condition is it updated?
Suggestions:
* The zoneinfo database is stored in the new package 'tzdata',
that's Lib/tzdata in the source dist. The files are kept in
our hg repository, too.
* A tool chain is provided that compiles the zoneinfos from a Olson
tar.gz file. (Bonus points for a download + update script). The
tool chain is included in source dist, e.g. Tools/.
* The db is updated on a regular basis during the development, alpha
and beta phase by any core dev. Every patch level release shall
contain the latest version of the db, maybe except for security
releases.
* 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.
Who is going to create the tzdata_update package, how is it compiled and
how often should it be released?
One other thing, the zoneinfo database should be compatible with zipfile
distributions. The module should be able to load the files from a stdlib
zipfile. The feature is important for freeze, py2exe and py2app.
Christian
Barry Warsaw
Dec 14, 2012, 10:29:03 AM12/14/12
to pytho...@python.org
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.
>* 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.
-Barry
Ben Finney
Dec 19, 2012, 7:18:59 PM12/19/12
to pytho...@python.org
Terry Reedy <tjr...@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?
>
> ValueError. That is what it is. Nothing special here.
I think it's useful to have this raise a custom exception
UnknownTimeZoneError, subclassed from ValueError. That satisfies those
(including me!) who think it should be a ValueError, while also making
the exception more specific so it can be handled apart from other
possible ValueError causes.
In short: +1 to ‘class UnknownTimeZoneError(ValueError)’.
--
\ “Members of the general public commonly find copyright rules |
`\ implausible, and simply disbelieve them.” —Jessica Litman, |
_o__) _Digital Copyright_ |
Ben Finney
Barry Warsaw
Dec 20, 2012, 11:43:15 AM12/20/12
to pytho...@python.org
On Dec 20, 2012, at 11:18 AM, Ben Finney wrote:
>Terry Reedy <tjr...@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?
>>
>> ValueError. That is what it is. Nothing special here.
>
>I think it's useful to have this raise a custom exception
>UnknownTimeZoneError, subclassed from ValueError. That satisfies those
>(including me!) who think it should be a ValueError, while also making
>the exception more specific so it can be handled apart from other
>possible ValueError causes.
>
>In short: +1 to ‘class UnknownTimeZoneError(ValueError)’.
That would be `class UnknownTimeZoneError(ValueError, TimeZoneError)`.
>Terry Reedy <tjr...@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?
>>
>> ValueError. That is what it is. Nothing special here.
>
>I think it's useful to have this raise a custom exception
>UnknownTimeZoneError, subclassed from ValueError. That satisfies those
>(including me!) who think it should be a ValueError, while also making
>the exception more specific so it can be handled apart from other
>possible ValueError causes.
>
>In short: +1 to ‘class UnknownTimeZoneError(ValueError)’.
-Barry
Lennart Regebro
Dec 28, 2012, 1:02:36 PM12/28/12
to Barry Warsaw, pytho...@python.org
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 be used for this UnknownTimeZoneError, so I'm not sure it has much value.
//Lennart
Terry Reedy
Dec 28, 2012, 3:45:37 PM12/28/12
to pytho...@python.org
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 opinions against that?
Since the erroneous value is used as a key for a database lookup, and
> 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 opinions against that?
the error is probably detected by trying the lookup, I think that is ok.
even if the user does not use []s.
> There is no TimeZoneError today, and it would only be used for this
> UnknownTimeZoneError, so I'm not sure it has much value.
Terry Jan Reedy
Steven D'Aprano
Dec 28, 2012, 8:23:00 PM12/28/12
to pytho...@python.org
On 29/12/12 05:02, 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 that?
The PEP says:
> 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?
* 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 isn't 100% clear to me from the PEP what a valid name string would be,
but I assume that it will accept anything that the time.tzset function
will accept:
http://docs.python.org/3/library/time.html#time.tzset
If so, then valid "name strings" may be either:
- strings which define the timezone rule explicitly, e.g:
'AEST-10AEDT-11,M10.5.0,M3.5.0'
- or for convenience, rules already defined in your OS's timezone database:
'Australia/Melbourne'
In either case, I don't think KeyError is the appropriate exception type.
I think that if I were to see a time zone string such as:
'Europe/Melbourne' # no such place
'Eorupe/Stockhome' # misspelled
'Etc/GMT+999' # invalid offset
'AEST+10ASDT+11,M1050,M350' # invalid starting and ending dates
'*&vbegs156s^g' # utter rubbish
I would describe it as an *invalid* timezone, not a "missing" timezone.
So ValueError is a more appropriate base exception than KeyError.
> There is no TimeZoneError today, and it would only be used for this
> UnknownTimeZoneError, so I'm not sure it has much value.
is shorter and easier to read, write and remember?
(We have KeyError rather than UnknownKeyError, NameError rather than
UnknownNameError, etc.)
--
Steven
Lennart Regebro
Dec 28, 2012, 11:40:54 PM12/28/12
to Steven D'Aprano, pytho...@python.org
On Sat, Dec 29, 2012 at 2:23 AM, Steven D'Aprano <st...@pearwood.info> wrote:
The PEP says:
* New function :``timezone(name=None, db_path=None)``It isn't 100% clear to me from the PEP what a valid name string would be,
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".
but I assume that it will accept anything that the time.tzset function
will accept:
No, valid names are the names of time zones in the zoneinfo database. There isn't really any usecase for defining up your own rules as that would mean that you want a time zone that doesn't exist, which seems a bit pointless. :-)
(We have KeyError rather than UnknownKeyError, NameError rather than
UnknownNameError, etc.)
Sure, but what would otherwise a KeyError be unless an unkown or non-existing key?
//Lennart
Steven D'Aprano
Dec 30, 2012, 5:19:54 AM12/30/12
to pytho...@python.org
On 29/12/12 15:40, Lennart Regebro wrote:
> On Sat, Dec 29, 2012 at 2:23 AM, Steven D'Aprano<st...@pearwood.info>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 isn't 100% clear to me from the PEP what a valid name string would be,
>> but I assume that it will accept anything that the time.tzset function
>> will accept:
>>
>
> No, valid names are the names of time zones in the zoneinfo database.
If I've understood it correctly, that contradicts the PEP. One example
> On Sat, Dec 29, 2012 at 2:23 AM, Steven D'Aprano<st...@pearwood.info>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 isn't 100% clear to me from the PEP what a valid name string would be,
>> but I assume that it will accept anything that the time.tzset function
>> will accept:
>>
>
> No, valid names are the names of time zones in the zoneinfo database.
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.
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, one Centos), but there is Etc/GMT. So I conclude
that the PEP allows timezone rules, not just names.
Either way, I think the PEP needs to clarify what counts as a valid name
string.
> There
> isn't really any usecase for defining up your own rules as that would mean
> that you want a time zone that doesn't exist, which seems a bit pointless.
> :-)
not the same as not existing in real life.
Perhaps the database is out-of-date, or the government has suddenly declared
a daylight savings change that isn't reflected yet in the database. Or you
want to set your own TZ rules for testing. Or you've just declared independence
from the central government and are setting up your own TZ rules.
time.tzset supports rules as well as names. Is there some reason why this
module should not do the same?
I also quote from /usr/share/doc/tzdata-2012f/README on my Centos system:
[quote]
README for the tz distribution
[...]
The 1989 update of the time zone package featured
[...]
* reference data from the United States Naval Observatory for folks who
want to do additional time zones
[end quote]
So the people who prepare tzdata on Red Hat systems clearly think that there
are use-cases for making additional time zones.
Tres Seaver
Dec 30, 2012, 11:39:21 AM12/30/12
to pytho...@python.org
-----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, one Centos), but there is Etc/GMT. So
> I conclude that the PEP allows timezone rules, not just names.
FWIW, my Ubuntu box has zone data for 'ETC/GMT+11':
$ file /usr/share/zoneinfo/posix/Etc/GMT+11
/usr/share/zoneinfo/posix/Etc/GMT+11: timezone data, version 2, \
1 gmt time flag, 1 std time flag, no leap seconds, no transition times, \
1 abbreviation char
Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 tse...@palladion.com
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlDgbjkACgkQ+gerLs4ltQ6w2QCgzqAFfOAigwVZMZEh+il+0grb
jsYAoMm1g8xnXe1dcgkFMEX0n14grDSH
=rCdb
-----END PGP SIGNATURE-----
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, one Centos), but there is Etc/GMT. So
> I conclude that the PEP allows timezone rules, not just names.
$ file /usr/share/zoneinfo/posix/Etc/GMT+11
/usr/share/zoneinfo/posix/Etc/GMT+11: timezone data, version 2, \
1 gmt time flag, 1 std time flag, no leap seconds, no transition times, \
1 abbreviation char
Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 tse...@palladion.com
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlDgbjkACgkQ+gerLs4ltQ6w2QCgzqAFfOAigwVZMZEh+il+0grb
jsYAoMm1g8xnXe1dcgkFMEX0n14grDSH
=rCdb
-----END PGP SIGNATURE-----
Lennart Regebro
Dec 31, 2012, 8:17:51 AM12/31/12
to Steven D'Aprano, pytho...@python.org
On Sun, Dec 30, 2012 at 11:19 AM, Steven D'Aprano <st...@pearwood.info> wrote:
If I've understood it correctly, that contradicts the PEP. One examplegiven 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 depends on your definition of a timezone name. There is no generally accepted authority for time zone names, the closest one we get is the zoneinfo database itself, which is maintained by ICANN. It has an Etc/GMT+11.
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
zone.tab contains none of the Etc/Something zones.
I looked at (one Debian, one Centos), but there is Etc/GMT. So I conclude
that the PEP allows timezone rules, not just names.
This is more problematic, and for that reason I'll change the PEP to use another example.
Either way, I think the PEP needs to clarify what counts as a valid name
string.
A timezone file that exists in the zoneinfo database used.
Perhaps the database is out-of-date, or the government has suddenly declared
a daylight savings change that isn't reflected yet in the database. Or you
want to set your own TZ rules for testing. Or you've just declared independence
from the central government and are setting up your own TZ rules.
time.tzset supports rules as well as names. Is there some reason why this
module should not do the same?
You will be able to make your own rules, the simplest is probably by adding it to your zoneinfo database. Doing so is however not trivial, and outside of the scope of this PEP.
//Lennart
Reply all
Reply to author
Forward
0 new messages