Draft PEP for time zone support.
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
On Tue, Dec 11, 2012 at 4:23 PM, Lennart Regebro
Proposal ========
The time zone support will be implemented by a new module called `timezone``, based on Stuart Bishop's ``pytz`` module.
I wonder if there needs to be something here about how to port from pytz to the new timezone library.
* New function :``get_timezone(name=None, db=None)``
This function takes a name string that must be a string specifying a valid zoneinfo timezone, ie "US/Eastern", "Europe/Warsaw" or "Etc/GMT+11". If not given, the local timezone will be looked up. If an invalid zone name are given, or the local timezone can not be retrieved, the function raises `UnknownTimeZoneError`.
The function also takes an optional path to the location of the zoneinfo database which should be used. If not specified, the function will check if the `timezonedata` module is installed, and then use that location or otherwise use the database in ``/usr/share/zoneinfo``.
If no database is found an ``UnknownTimeZoneError`` or subclass thereof will be raised with a message explaining that no zoneinfo database can be found, but that you can install one with the ``timezonedata`` package.
It seems like calling get_timezone() with an unknown timezone should just throw ValueError, not necessarily some custom Exception? It would probably be a good idea to have a different exception for the case of no database available.
Differences from the ``pytz`` API =================================
* ``pytz`` has the functions ``localize()`` and ``normalize()`` to work around that ``tzinfo`` doesn't have is_dst. When ``is_dst`` is implemented directly in ``datetime.tzinfo`` they are no longer needed.
* The ``pytz`` method ``timezone()`` is instead called ``get_timezone()`` for clarity.
* ``get_timezone()`` will return the local time zone if called without parameters.
* The class ``pytz.StaticTzInfo`` is there to provide the ``is_dst`` support for static timezones. When ``is_dst`` support is included in ``datetime.tzinfo`` it is no longer needed.
This feels a bit superfluous. Why not keep a bit more of the pytz API to make porting easy? The pytz API has proven itself in the wild, so I don't see much point in renaming "for clarity". It also seems relatively painless to keep localize() and normalize() functions around for easy porting.
Discussion ==========
Should the windows installer include the data package? ------------------------------------------------------
It has been suggested that the Windows installer should include the data package. This would mean that an explicit installation no longer would be needed on Windows. On the other hand, that would mean that many using Windows would not be aware that the database quickly becomes outdated and would not keep it updated.
I still submit that it's pretty much just as easy to forget to update the database whether it's been installed by hand zero or one times, so I don't find your argument convincing. I don't mind the result much, though. Looking forward to have timezone support in the stdlib! Cheers, Dirkjan
On 11 December 2012 15:39, Dirkjan Ochtman
Should the windows installer include the data package? ------------------------------------------------------
It has been suggested that the Windows installer should include the data package. This would mean that an explicit installation no longer would be needed on Windows. On the other hand, that would mean that many using Windows would not be aware that the database quickly becomes outdated and would not keep it updated.
I still submit that it's pretty much just as easy to forget to update the database whether it's been installed by hand zero or one times, so I don't find your argument convincing. I don't mind the result much, though.
I agree. Also, in corporate or similar environments where each individual package installation must be approved, having at least some timezone data in the base install ensures that all Python code can assume the *existence* of timezone support (if not necessarily the accuracy of that data). If the base Windows installer does not include timezone data, then the documentation should note this and offer advice on how to write code that degrades gracefully without timezones. If the base installer *does* include timezone data, of course, there should be a documented mechanism for updating it (we don't want magic like the old xml package used, I assume). Paul.
On Tue, Dec 11, 2012 at 9:48 AM, Paul Moore
On 11 December 2012 15:39, Dirkjan Ochtman
wrote: Should the windows installer include the data package? ------------------------------------------------------
It has been suggested that the Windows installer should include the data package. This would mean that an explicit installation no longer would be needed on Windows. On the other hand, that would mean that many using Windows would not be aware that the database quickly becomes outdated and would not keep it updated.
I still submit that it's pretty much just as easy to forget to update the database whether it's been installed by hand zero or one times, so I don't find your argument convincing. I don't mind the result much, though.
I agree. Also, in corporate or similar environments where each individual package installation must be approved, having at least some timezone data in the base install ensures that all Python code can assume the *existence* of timezone support (if not necessarily the accuracy of that data).
If the base Windows installer does not include timezone data, then the documentation should note this and offer advice on how to write code that degrades gracefully without timezones.
If the base installer *does* include timezone data, of course, there should be a documented mechanism for updating it (we don't want magic like the old xml package used, I assume).
I think we should try to get the data into the base installer and then include a small updater, perhaps putting it in a Windows scheduled task and checking PyPI periodically for newer versions. If a new one comes up, prompt if the user wants it.
Le Tue, 11 Dec 2012 16:23:37 +0100,
Lennart Regebro
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.
On Dec 11, 2012, at 04:23 PM, Lennart Regebro wrote:
This PEP is also available on github:
wget returns some html gobbledygook. Why-oh-why github?!
PEP: 4??
I've assigned this PEP 431, reformatted a few extra wide paragraphs, committed and pushed. Thanks Lennart! -Barry
On Tuesday, December 11, 2012 at 3:31 PM, Barry Warsaw wrote:
On Dec 11, 2012, at 04:23 PM, Lennart Regebro wrote:
This PEP is also available on github:
wget returns some html gobbledygook. Why-oh-why github?!' wget https://raw.github.com/regebro/tz-pep/master/pep-04tz.txt
PEP: 4??
I've assigned this PEP 431, reformatted a few extra wide paragraphs, committed and pushed.
Thanks Lennart! -Barry
_______________________________________________ Python-Dev mailing list Python-Dev@python.org (mailto:Python-Dev@python.org) http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/donald.stufft%40gmail.com
Barry you want github raw:
https://raw.github.com/regebro/tz-pep/master/pep-04tz.txt
On Tue, Dec 11, 2012 at 3:31 PM, Barry Warsaw
On Dec 11, 2012, at 04:23 PM, Lennart Regebro wrote:
This PEP is also available on github:
wget returns some html gobbledygook. Why-oh-why github?!
PEP: 4??
I've assigned this PEP 431, reformatted a few extra wide paragraphs, committed and pushed.
Thanks Lennart! -Barry
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/quodlibetor%40gmail.com
On Tue, Dec 11, 2012 at 8:07 AM, Antoine Pitrou
Le Tue, 11 Dec 2012 16:23:37 +0100, Lennart Regebro
a écrit : Changes in the ``datetime``-module --------------------------------------
A new ``is_dst`` parameter is added to several of the `tzinfo` methods to handle time ambiguity during DST changeovers.
* ``tzinfo.utcoffset(self, dt, is_dst=True)``
* ``tzinfo.dst(self, dt, is_dst=True)``
* ``tzinfo.tzname(self, dt, is_dst=True)``
The ``is_dst`` parameter can be ``True`` (default), ``False``, or ``None``.
``True`` will specify that the given datetime should be interpreted as happening during daylight savings time, ie that the time specified is before the change from DST.
Why is it True by default? Do we have statistics showing that Python gets more use in summer?
My question exactly. The rest sounds good -- definitely use the system tz database on Unixy systems, pre-install on Windows and make updating easy. Some bikeshedding about static I don't really understand, so I'll leave to others. -- --Guido van Rossum (python.org/~guido)
On Wed, Dec 12, 2012 at 1:23 AM, Lennart Regebro
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 | ncoghlan@gmail.com | Brisbane, Australia
Guido van Rossum wrote:
Sent: Tuesday, December 11, 2012 4:11 PM To: Antoine Pitrou Cc: python-dev@python.org Subject: Re: [Python-Dev] Draft PEP for time zone support.
On Tue, Dec 11, 2012 at 8:07 AM, Antoine Pitrou
wrote: Le Tue, 11 Dec 2012 16:23:37 +0100, Lennart Regebro
a écrit : Changes in the ``datetime``-module --------------------------------------
A new ``is_dst`` parameter is added to several of the `tzinfo` methods to handle time ambiguity during DST changeovers.
* ``tzinfo.utcoffset(self, dt, is_dst=True)``
* ``tzinfo.dst(self, dt, is_dst=True)``
* ``tzinfo.tzname(self, dt, is_dst=True)``
The ``is_dst`` parameter can be ``True`` (default), ``False``, or ``None``.
``True`` will specify that the given datetime should be interpreted as happening during daylight savings time, ie that the time
specified
is before the change from DST.
Why is it True by default? Do we have statistics showing that Python gets more use in summer?
My question exactly.
"Summer" in the USA, at least, is 238 days in 2012, while "Winter" into 2013 is only 126 days:
import datetime datetime.date(2012, 11, 4) - datetime.date(2012, 3, 11) datetime.timedelta(238) datetime.date(2013, 3, 10) - datetime.date(2012, 11, 4) datetime.timedelta(126)
Robert Brewer fumanchu@aminus.org
On Tue, Dec 11, 2012 at 5:11 PM, Robert Brewer
Guido van Rossum wrote:
Sent: Tuesday, December 11, 2012 4:11 PM To: Antoine Pitrou Cc: python-dev@python.org Subject: Re: [Python-Dev] Draft PEP for time zone support.
On Tue, Dec 11, 2012 at 8:07 AM, Antoine Pitrou
wrote: Le Tue, 11 Dec 2012 16:23:37 +0100, Lennart Regebro
a écrit : Changes in the ``datetime``-module --------------------------------------
A new ``is_dst`` parameter is added to several of the `tzinfo` methods to handle time ambiguity during DST changeovers.
* ``tzinfo.utcoffset(self, dt, is_dst=True)``
* ``tzinfo.dst(self, dt, is_dst=True)``
* ``tzinfo.tzname(self, dt, is_dst=True)``
The ``is_dst`` parameter can be ``True`` (default), ``False``, or ``None``.
``True`` will specify that the given datetime should be interpreted as happening during daylight savings time, ie that the time
specified
is before the change from DST.
Why is it True by default? Do we have statistics showing that Python gets more use in summer?
My question exactly.
"Summer" in the USA, at least, is 238 days in 2012, while "Winter" into 2013 is only 126 days:
import datetime datetime.date(2012, 11, 4) - datetime.date(2012, 3, 11) datetime.timedelta(238) datetime.date(2013, 3, 10) - datetime.date(2012, 11, 4) datetime.timedelta(126)
Very funny, but that can't be the real reason. *Most* datetime values aren't ambiguous, so in those cases the parameter should be ignored, right? There's only one hour per year where you need to specify it (two, if we want to artificially assign a meaning to values falling the impossible hour). And during those times it's equally likely that you meant either of the possibilities. I think the meaning of the parameter must be clarified, perhaps as follows: - ignored except during the ambiguous hour and during the impossible hour - during the ambiguous or impossible hour: - if True, prefer/pretend DST - if False, prefer/pretend non-DST - if None, raise an error Here I'd prefer the default to be None if I had to do it over again, but given that the current behavior is one of the first two (which one?) we probably can't do that. Still, it's slightly confusing that passing None is not the same as omitting the parameter altogether -- there aren't many APIs that explicitly support passing None but don't use it as the default (though there probably are some precedents). Maybe requesting an error should be done through some other special value, and None should be the same as omitted and the same as the old behavior? But where would the special value come from? It should be made as easy as possible to "do the right thing" (i.e. raise an error). Or maybe have a separate Boolean flag to request an error? -- --Guido van Rossum (python.org/~guido)
Great work, Lennart. I really like this PEP. Feedback follows (I haven't yet read the rest of the messages in this thread ;). On Dec 11, 2012, at 04:23 PM, Lennart Regebro wrote:
This PEP proposes to add these ``is_dst`` parameters to the relevant methods of the ``datetime`` API, and therefore add this functionality directly to ``datetime``. This is likely the hardest part of this PEP as this involves updating the
Oops, something got cut off there.
The new ``timezone``-module ---------------------------
The public API of the new ``timezone``-module contains one new class, one new function and one new exception.
Why add a new module instead of putting all this into the existing datetime module, either directly or as a submodule? Seems like the obvious place to put it instead of claiming another top-level module name.
* New class: ``DstTzInfo``
This class provides a concrete implementation of the ``zoneinfo`` base class that implements DST support.
Is this a subclass of datetime.tzinfo?
* New function :``get_timezone(name=None, db=None)``
This function takes a name string that must be a string specifying a valid zoneinfo timezone, ie "US/Eastern", "Europe/Warsaw" or "Etc/GMT+11". If not given, the local timezone will be looked up. If an invalid zone name are given, or the local timezone can not be retrieved, the function raises `UnknownTimeZoneError`.
The function also takes an optional path to the location of the zoneinfo database which should be used. If not specified, the function will check if the `timezonedata` module is installed, and then use that location or otherwise use the database in ``/usr/share/zoneinfo``.
I'm bikeshedding, but can we find a better name than `db` for the second argument? Something that makes it obvious we're looking for file system path?
* New Exception: ``UnknownTimeZoneError``
I'd really like to see a TimeZoneError base class from which all these new exceptions inherit.
A new ``is_dst`` parameter is added to several of the `tzinfo` methods to handle time ambiguity during DST changeovers.
* ``tzinfo.utcoffset(self, dt, is_dst=True)``
I lied a little bit - I did skim the other messages, so I'll reserve comment on the default value of is_dst for follow ups.
* ``AmbiguousTimeError``
* ``NonExistentTimeError``
I'm not positive we need separate exceptions here, but I guess it can't hurt, and with the base class idea above, we can catch both either explicitly, or by catching the base class.
The ``timezonedata``-package -----------------------------
Just to be clear, this doesn't expose any new modules, right? Cheers, -Barry
On Dec 11, 2012, at 03:48 PM, Paul Moore wrote:
I agree. Also, in corporate or similar environments where each individual package installation must be approved, having at least some timezone data in the base install ensures that all Python code can assume the *existence* of timezone support (if not necessarily the accuracy of that data).
One other thing that the PEP should describe is what happens on a distro that has timezone data, but which you also pip install the PyPI tzdata package. Which one wins? Is there a way to control it, other than providing an explicit path? Is there a way to uninstall the PyPI package? Does the API need to provide a method which tells you where the database it is using by default lives? Cheers, -Barry
On Dec 11, 2012, at 04:23 PM, Lennart Regebro wrote:
A new ``is_dst`` parameter is added to several of the `tzinfo` methods to handle time ambiguity during DST changeovers.
``None`` will raise an ``AmbiguousTimeError`` exception if the time specified was during a DST change over. It will also raise a ``NonExistentTimeError`` if a time is specified during the "missing time" in a change to DST.
I think None should be the default. -Barry
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
On Wed, Dec 12, 2012 at 12:58 PM, Barry Warsaw
On Dec 11, 2012, at 04:23 PM, Lennart Regebro wrote:
A new ``is_dst`` parameter is added to several of the `tzinfo` methods to handle time ambiguity during DST changeovers.
``None`` will raise an ``AmbiguousTimeError`` exception if the time specified was during a DST change over. It will also raise a ``NonExistentTimeError`` if a time is specified during the "missing time" in a change to DST.
I think None should be the default.
That's a backwards compatibility risk, though - many applications are likely coping just fine with the slightly corrupted time values, but would fall over if an exception was raised instead. The default should probably be chosen so that the single argument form of these calls continues to behave the same in 3.4 as it does in 3.3, emitting a DeprecationWarning to say that the default behaviour is going to change in 3.5 (so the *actual* default would be sentinel value, in order to tell the difference between an explicit True being passed and relying on the default behaviour). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
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 Cheers, -Barry
On Tue, Dec 11, 2012 at 7:19 PM, Barry Warsaw
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.
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
I don't think it's worth deprecating the old behavior. -- --Guido van Rossum (python.org/~guido)
On 12 December 2012 00:58, Nick Coghlan
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 shipping the package and some sort of auto-updater, too. Paul
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.
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).
+1, too.
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
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
The ``is_dst`` parameter can be ``True`` (default), ``False``, or ``None``.
Why is it True by default? Do we have statistics showing that Python gets more use in summer?
Because for some reason both me and Stuart Bishop thought it should be, but
at least in my case I don't have any actual good reason why. Checking with
how pytz does this shows that pytz in fact defaults to False, so I think
the default should be False.
On Wed, Dec 12, 2012 at 3:50 AM, Barry Warsaw
This is likely the hardest part of this PEP as this involves updating the
Oops, something got cut off there.
Ah, yes, I was going to write that the difficult bit was updating the _datetime.c module.
Why add a new module instead of putting all this into the existing datetime module, either directly or as a submodule? Seems like the obvious place to put it instead of claiming another top-level module name.
pytz as it is consists of several modules, and a significant amount of code, it didn't feel right to move all that into the datetime.py module. It also didn't feel right to then not implement it in _datetime.c, but perhaps that's just me being silly. But a submodule could work.
I'm bikeshedding, but can we find a better name than `db` for the second argument? Something that makes it obvious we're looking for file system path?
Absolutely. db_path?
I'd really like to see a TimeZoneError base class from which all these new exceptions inherit.
That makes sense.
The ``timezonedata``-package -----------------------------
Just to be clear, this doesn't expose any new modules, right?
That's the intention, yes, although I haven't investigated ways of knowing if it's installed or not yet, and exposing a module is the obvious way of doing that. But I'm hoping there will be better ways, right?
One other thing that the PEP should describe is what happens on a distro that has timezone data, but which you also pip install the PyPI tzdata package. Which one wins? Is there a way to control it, other than providing an explicit path? Is there a way to uninstall the PyPI package? Does the API need to provide a method which tells you where the database it is using by default lives?
The PyPI package wins, I'll clarify that bit. I'm think the data should end
up in site-packages somewhere, and that it should be installable and
uninstallable with pip/easy_install and by simply deleting it.
On Wed, Dec 12, 2012 at 4:14 AM, Nick Coghlan
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).
Although explicit is better than implicit, I think this is one case where 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.
On Wed, Dec 12, 2012 at 9:56 AM, Lennart Regebro
General comments:
It seems like the consensus is moving towards making sure there always is a database available. If this means including it in the standard Python distribution as well, or only on Windows, I don't know, opinions on that are welcome.
The steps to look for a database would then change to:
1. The path specified, if not None.
2. The module for timezone "overrides".
3. The OS database.
4. The database included in Python.
We need to determine if a warning should be raised in case of 4 or not, as well as the name for the override module. I think the word "override" here is possibly unclear, I'd prefer something like "timezone-update" or similar.
I'm personally a bit sceptical to writing a special updater/installer just for this. I don't want to have a special unique way to install this package.
As it comes to OS packages, Christian Heimes pointed out that most Windows installations today has Java installed, and kept updated, and it has a zoneinfo database. We could consider using that on Windows as well, although it admittedly feels quite icky.
Depending on Java being installed or even installing it alongside Python would be a funny April Fools prank. This can't happen. I don't think it's all that bad to include a small script on Windows which runs every few days to check PyPI, then present an option to update the info. This is what Java itself is doing anyway.
On Wed, Dec 12, 2012 at 4:56 PM, Lennart Regebro
Why not keep a bit more of the pytz API to make porting easy?
The renaming of the timezone() function to get_timezone() is indeed small, but changing pytz.timezone(foo) to timezone.timezone(foo) is really significantly easier than renaming it to timezone.get_timezone(foo).
If we keep all of the API intact you could do
try: import pytz as timezone except ImportError: import timezone
Which would make porting quicker, that's true, but do we really want to keep unecessary API's around forever? Isn't it better to minimize the noise from the start?
That entirely depends on when you define to be "the start". It seems to me the consensus on python-dev has been that packages primarily evolve outside the stdlib; it seems a bit weird to then, at the time of stdlib inclusion, start changing the API.
Why is it True by default? Do we have statistics showing that Python gets more use in summer?
Because for some reason both me and Stuart Bishop thought it should be, but at least in my case I don't have any actual good reason why. Checking with how pytz does this shows that pytz in fact defaults to False, so I think the default should be False.
Here, too, I think that sticking with pytz's default would be a good idea. Cheers, Dirkjan
On 12 December 2012 16:11, Brian Curtin
I don't think it's all that bad to include a small script on Windows which runs every few days to check PyPI, then present an option to update the info. This is what Java itself is doing anyway.
What would that do in an environment without internet access? Or with a firewall blocking Python's requests and returning an error page without warning (so the updater just sees incorrect data)? What about corporate environments that want to control the rollout of updates? (I can't imagine that in practice, but certainly companies do it for Java). Most Windows updaters use the "official" Windows APIs so that they work properly with odd cases like ISA proxies taking credentials from the Windows user login. Python's stdlib doesn't support that type of thing. I'm -1 on auto-updating because it's too easy to produce a "nearly right" solution that doesn't work in highly-controlled (e.g., corporate) environments. And a "correct" solution would be hard to support with python-dev's level of Windows expertise. Paul.
Le Wed, 12 Dec 2012 10:11:15 -0600,
Brian Curtin
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.
On Wed, Dec 12, 2012 at 8:44 AM, Antoine Pitrou
Le Wed, 12 Dec 2012 10:11:15 -0600, Brian Curtin
a écrit : I don't think it's all that bad to include a small script on Windows which runs every few days to check PyPI, then present an option to update the info. This is what Java itself is doing anyway.
I don't get why people are so obsessed about updating the timezone database. Really, this is not worse than having a vulnerable OpenSSL linked with your Python executable. Purity does not bring any advantage here.
Bingo. As long as the recipe to update is clear, most users can ignore this, because the countries about which they care don't change DST rules often enough for it to matter. When it does matter, they'll know (changing the DST rules is something that local news sources tend to track :-) and they can update their software when stuff they use starts getting the time wrong. Obviously sysadmins responsible for large numbers of users can make this into a routine, and ditto people who run services. But these folks are professionals and are good at automating tasks like this. -- --Guido van Rossum (python.org/~guido)
Paul Moore wrote:
On 12 December 2012 16:11, Brian Curtin
wrote: I don't think it's all that bad to include a small script on Windows which runs every few days to check PyPI, then present an option to update the info. This is what Java itself is doing anyway.
What would that do in an environment without internet access? Or with a firewall blocking Python's requests and returning an error page without warning (so the updater just sees incorrect data)? What about corporate environments that want to control the rollout of updates? (I can't imagine that in practice, but certainly companies do it for Java). Most Windows updaters use the "official" Windows APIs so that they work properly with odd cases like ISA proxies taking credentials from the Windows user login. Python's stdlib doesn't support that type of thing.
I'm -1 on auto-updating because it's too easy to produce a "nearly right" solution that doesn't work in highly-controlled (e.g., corporate) environments. And a "correct" solution would be hard to support with python-dev's level of Windows expertise.
And what about embedded installations of Python, such as in TortoiseHg? And all the people (such as myself) who disable updaters that they don't like or didn't expect? The "correct" solution on Windows may be to use a static database for historical dates and the information in the registry for current and future dates. The registry is updated through Windows Update, which is at least as reliable as anything Python could do. (I'm not sure exactly what the state of updates to older versions is like, but I'd assume WinXP still gets timezone updates and Win2K doesn't.) Details of the registry entries are at http://msdn.microsoft.com/en-us/library/ms725481.aspx. It looks like the data is focused on modern timezones rather than localities, which would mean a many-to-one mapping from zoneinfo. Unfortunately it doesn't look like there's enough overlap to allow an automated mapping. That said, it is incredibly easy to convert between UTC and local (http://msdn.microsoft.com/en-us/library/ms724949.aspx), even for dates in the past or future when the information is available. It's just that timezones other than the user's preference are difficult. Cheers, Steve
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
On 12.12.12 02:43, Guido van Rossum wrote:
Guido van Rossum wrote:
Sent: Tuesday, December 11, 2012 4:11 PM To: Antoine Pitrou Cc:python-dev@python.org Subject: Re: [Python-Dev] Draft PEP for time zone support.
On Tue, Dec 11, 2012 at 8:07 AM, Antoine Pitrou
wrote: Le Tue, 11 Dec 2012 16:23:37 +0100, Lennart Regebro
a écrit : Changes in the ``datetime``-module --------------------------------------
A new ``is_dst`` parameter is added to several of the `tzinfo` methods to handle time ambiguity during DST changeovers.
* ``tzinfo.utcoffset(self, dt, is_dst=True)``
* ``tzinfo.dst(self, dt, is_dst=True)``
* ``tzinfo.tzname(self, dt, is_dst=True)``
The ``is_dst`` parameter can be ``True`` (default), ``False``, or ``None``.
``True`` will specify that the given datetime should be interpreted as happening during daylight savings time, ie that the time specified is before the change from DST. Why is it True by default? Do we have statistics showing that Python gets more use in summer? My question exactly. "Summer" in the USA, at least, is 238 days in 2012, while "Winter" into 2013 is only 126 days:
import datetime datetime.date(2012, 11, 4) - datetime.date(2012, 3, 11) datetime.timedelta(238) datetime.date(2013, 3, 10) - datetime.date(2012, 11, 4) datetime.timedelta(126) Very funny, but that can't be the real reason. *Most* datetime values aren't ambiguous, so in those cases the parameter should be ignored, right? There's only one hour per year where you need to specify it (two, if we want to artificially assign a meaning to values falling
On Tue, Dec 11, 2012 at 5:11 PM, Robert Brewer
wrote: the impossible hour). And during those times it's equally likely that you meant either of the possibilities. I think the meaning of the parameter must be clarified, perhaps as follows: - ignored except during the ambiguous hour and during the impossible hour - during the ambiguous or impossible hour: - if True, prefer/pretend DST - if False, prefer/pretend non-DST - if None, raise an error
Here I'd prefer the default to be None if I had to do it over again, but given that the current behavior is one of the first two (which one?) we probably can't do that. Still, it's slightly confusing that passing None is not the same as omitting the parameter altogether -- there aren't many APIs that explicitly support passing None but don't use it as the default (though there probably are some precedents). Maybe requesting an error should be done through some other special value, and None should be the same as omitted and the same as the old behavior? But where would the special value come from? It should be made as easy as possible to "do the right thing" (i.e. raise an error). Or maybe have a separate Boolean flag to request an error?
I see an issue here that makes me a little uncomfortable: Having a default that makes code work all year but raises an error during the "impossible hour" could be problematic in critical code. Can we make this more explicit by forcing the users to decide? I like the idea of the extra boolean flag here, because it will be explicitly visible that this code intentionally creates an exception. Or even not a flag, but the exception to be raised, or a callable to handle this case? Sloppy coding can be dangerous. So maybe the warning module could be helpful as well: If None is passed and no explicit flag/exception/callable given, bother the user with a warning message ;-) cheers - chris -- Christian Tismer :^)mailto:tismer@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/
On Wed, Dec 12, 2012 at 5:21 PM, Dirkjan Ochtman
That entirely depends on when you define to be "the start". It seems to me the consensus on python-dev has been that packages primarily evolve outside the stdlib; it seems a bit weird to then, at the time of stdlib inclusion, start changing the API.
But this bit of the API is there only as a hack, because stdlib does not support is_dst. We are changing that. Hence those extra functions are no longer needed. //Lennart
On Wed, Dec 12, 2012 at 5:54 PM, Steve Dower
Details of the registry entries are at http://msdn.microsoft.com/en-us/library/ms725481.aspx. It looks like the data is focused on modern timezones rather than localities, which would mean a many-to-one mapping from zoneinfo. Unfortunately it doesn't look like there's enough overlap to allow an automated mapping.
No, but the Unicode consortium (I think) is keeping a mapping updated manually. I'm using that in tzlocal, to figure out the local timezone of the computer on Windows. However, I think that mixing and matching timezone data in this way from the two systems are likely to be full of pitfalls edge-cases and complexities I do not dare even think seriously about. There will probably be *less* errors by just keeping an old timezone database around. Besides, what it they don't run Windows update? Then the data still is outdated? //Lennart
On 12/12/2012 11:53 AM, Guido van Rossum wrote:
Bingo. As long as the recipe to update is clear, most users can ignore this, because the countries about which they care don't change DST rules often enough for it to matter. When it does matter, they'll know (changing the DST rules is something that local news sources tend to track :-) and they can update their software when stuff they use starts getting the time wrong. Obviously sysadmins responsible for large numbers of users can make this into a routine, and ditto people who run services. But these folks are professionals and are good at automating tasks like this.
As a Windows user, I would like there to be one tz data file used by all Python versions on my machine, including ones included with other apps. I would like every installer, including for bug fix releases, to update it. This should be sufficient for 99% of Windows users. As Guido says above, the docs should tell the other 1% how to update it explicitly. -- Terry Jan Reedy
On 12/12/2012 10:56 AM, Lennart Regebro wrote:
It seems like calling get_timezone() with an unknown timezone should just throw ValueError, not necessarily some custom Exception?
That could very well be. What are others opinions on this?
ValueError. That is what it is. Nothing special here.
Why not keep a bit more of the pytz API to make porting easy?
The renaming of the timezone() function to get_timezone() is indeed small,
And gratuitous, to me. I don't generally like 'get' prefixes anyway.
but changing pytz.timezone(foo) to timezone.timezone(foo) is really significantly easier than renaming it to timezone.get_timezone(foo).
If we keep all of the API intact you could do
try: import pytz as timezone except ImportError: import timezone
Which would make porting quicker, that's true, but do we really want to keep unecessary API's around forever? Isn't it better to minimize the noise from the start?
While the module that was the basis for the ipaddress module was released on PyPI and its api developed however it did, the API was worked over quite a bit before the addition of ipaddress. So I agree that the current api can be revised before being more-or-less frozen in the stdlib.
It also seems relatively painless to keep localize() and normalize() functions around for easy porting.
Sure, but you then have two ways of doing the same thing, which I think we should avoid.
I agree that this is precisely the time to remove cruft (if indeed it is such). -- Terry Jan Reedy
On Thu, Dec 13, 2012 at 12:23 AM, Terry Reedy
As a Windows user, I would like there to be one tz data file used by all Python versions on my machine, including ones included with other apps.
That would be nice, but where would that be installed? There is no standard location for zoneinfo files. And do we really want to install python-specific files outside the Python tree? //Lennart
On 2012-12-12 23:33, Lennart Regebro wrote:
On Thu, Dec 13, 2012 at 12:23 AM, Terry Reedy
wrote: As a Windows user, I would like there to be one tz data file used by all Python versions on my machine, including ones included with other apps.
That would be nice, but where would that be 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.
On Wed, Dec 12, 2012 at 6:10 PM, MRAB
On 2012-12-12 23:33, Lennart Regebro wrote:
On Thu, Dec 13, 2012 at 12:23 AM, Terry Reedy
wrote: As a Windows user, I would like there to be one tz data file used by all Python versions on my machine, including ones included with other apps.
That would be nice, but where would that be 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 12/12/2012 7:27 PM, Brian Curtin wrote:
On Wed, Dec 12, 2012 at 6:10 PM, MRAB
wrote: On 2012-12-12 23:33, Lennart Regebro wrote:
On Thu, Dec 13, 2012 at 12:23 AM, Terry Reedy
wrote: As a Windows user, I would like there to be one tz data file used by all Python versions on my machine, including ones included with other apps.
That would be nice, but where would that be installed? There is no standard location for zoneinfo files. And do we really want to install python-specific files outside the Python tree?
There is no 'Python tree' on windows. Rather, there is a separate tree for each version, located where the user directs. Windows used to have a %APPDATA% directory variable. Not sure about Win 7, let alone 8. Martin and others should know better. Or ask the user where to put it. I know where I would choose, and it would not be on my C drive. Un-installers would not delete (unless a reference count were kept and were decremented to 0).
Python version x.y is installed into, say, C:\Pythonxy, so perhaps a good place would be, say, C:\Python.
C:\ProgramData\Python
Making a new top-level directory without asking is obnoxious. -- Terry Jan Reedy
On Dec 12, 2012 7:24 PM, "Terry Reedy"
On 12/12/2012 7:27 PM, Brian Curtin wrote:
On Wed, Dec 12, 2012 at 6:10 PM, MRAB
wrote: On 2012-12-12 23:33, Lennart Regebro wrote:
On Thu, Dec 13, 2012 at 12:23 AM, Terry Reedy
wrote: As a Windows user, I would like there to be one tz data file used by
all
Python versions on my machine, 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-programd...
On 12/12/2012 5:36 PM, Brian Curtin wrote:
C:\ProgramData\Python
^^^^^ That. Is not the path that the link below is talking about, though.
Making a new top-level directory without asking is obnoxious.
See http://stackoverflow.com/questions/9518890/what-is-the-significance-programd...
On 12/12/2012 8:43 PM, Glenn Linderman wrote:
On 12/12/2012 5:36 PM, Brian Curtin wrote:
C:\ProgramData\Python
^^^^^ That. Is not the path that the link below is talking about, though.
It actually does; it is rather confusing though. :/ It's referring to KNOWNFOLDERID constant FOLDERID_ProgramData. The actual on disk location for this has changed over windows versions. As noted below in the SO link given: "Note that this documentation refers to the typical path as per older versions of Windows. In modern versions of Windows it is located in %SystemDrive%\ProgramData."
Making a new top-level directory without asking is obnoxious.
See http://stackoverflow.com/questions/9518890/what-is-the-significance-programd...
On Wed, Dec 12, 2012 at 8:10 PM, Janzert
On 12/12/2012 8:43 PM, Glenn Linderman wrote:
On 12/12/2012 5:36 PM, Brian Curtin wrote:
C:\ProgramData\Python
^^^^^ That. Is not the path that the link below is talking about, though.
It actually does; it is rather confusing though. :/ It's referring to KNOWNFOLDERID constant FOLDERID_ProgramData. The actual on disk location for this has changed over windows versions. As noted below in the SO link given:
"Note that this documentation refers to the typical path as per older versions of Windows. In modern versions of Windows it is located in %SystemDrive%\ProgramData."
Correct. Anyway, on with the actual timezone stuff...
On Thu, Dec 13, 2012 at 2:24 AM, Terry Reedy
Or ask the user where to put it.
If we ask where it should be installed, then we need a registry setting for that or we don't know where it's located when it is to be used. And if we ask, then people will install it in non-standard locations. While installers for software with Python don't want their users to be asked, so they'll install it in the standard location, overriding the managers preferred, updated custom location with the standard location with a database that is probably not updated. So I think that asking is not an option at all. It either goes in %PROGRAMDATA%\Python\zoneinfo or it's not shared at all.
I know where I would choose, and it would not be on my C drive. Un-installers would not delete (unless a reference count were kept and were decremented to 0).
True, and that's annoying when those counters go wrong. All in all I would say I would prefer to install this per Python. //Lennart
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.
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-programd...
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 specifically is at http://msdn.microsoft.com/en-us/library/windows/desktop/dd378457.aspx#FOLDER... 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-programd...
On 12/13/2012 1:06 AM, Lennart Regebro wrote:
On Thu, Dec 13, 2012 at 2:24 AM, Terry Reedy
wrote: Or ask the user where to put it.
If we ask where it should be installed, then we need a registry setting for that
Right.
So I think that asking is not an option at all. It either goes in %PROGRAMDATA%\Python\zoneinfo or it's not shared at all.
If that works for all xp+ versions, fine.
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.
It seems to me that Windows has a mechanism for this, at least in some versions. But maybe it only works for dlls.
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. -- Terry Jan Reedy
On 12/12/2012 11:32 PM, Janzert wrote:
On 12/13/2012 1:39 AM, Glenn Linderman wrote:
On 12/12/2012 6:10 PM, Janzert wrote:
On 12/12/2012 8:43 PM, Glenn Linderman wrote:
On 12/12/2012 5:36 PM, Brian Curtin wrote:
> C:\ProgramData\Python
^^^^^ That. Is not the path that the link 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 specifically is at
http://msdn.microsoft.com/en-us/library/windows/desktop/dd378457.aspx#FOLDER...
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
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!
On Thu, Dec 13, 2012 at 9:22 AM, Terry Reedy
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. //Lennart
Le Thu, 13 Dec 2012 10:07:34 +0100,
Lennart Regebro
On Thu, Dec 13, 2012 at 9:22 AM, Terry Reedy
wrote: On 12/13/2012 1:06 AM, Lennart Regebro wrote:
All in all I would say I would prefer to install this per Python.
Then explicit update requires multiple downloads or copying. This is a violation of DRY. If if is not too large, it would 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.
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 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
On 12/13/2012 4:07 AM, Lennart Regebro wrote:
On Thu, Dec 13, 2012 at 9:22 AM, Terry Reedy
wrote: On 12/13/2012 1:06 AM, Lennart Regebro wrote:
All in all I would say I would prefer to install this per Python.
Then explicit update requires multiple downloads or copying. This is a violation 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 '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,
An email or so ago, you said that the tz database should go in 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.
I *never* suggested this. In fact, I said that installing an updated 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 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.
When I suggested that users be able to put the database where they want, *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
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
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 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
Terry Reedy
On 12/12/2012 10:56 AM, Lennart Regebro wrote:
It seems like calling get_timezone() with an unknown timezone should just throw ValueError, not necessarily some custom Exception?
That could very well be. What are others opinions on this?
ValueError. That is what it is. Nothing special here.
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
On Dec 20, 2012, at 11:18 AM, Ben Finney wrote:
Terry Reedy
writes: On 12/12/2012 10:56 AM, Lennart Regebro wrote:
It seems like calling get_timezone() with an unknown timezone should just throw ValueError, not necessarily some custom Exception?
That could 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)`. -Barry
On Thu, Dec 20, 2012 at 5:43 PM, Barry Warsaw
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
On Dec 28, 2012, at 07:02 PM, Lennart Regebro wrote:
On Thu, Dec 20, 2012 at 5:43 PM, Barry Warsaw
wrote: That would be `class UnknownTimeZoneError(ValueError, TimeZoneError)`.
As of today, in Pytz, UnknownTimeZoneError in fact subclasses KeyError. Any opinions against that? There is no TimeZoneError today, and it would only be used for this UnknownTimeZoneError, so I'm not sure it has much value.
Agreed. If this is the only exception defined in the module, it sounds fine to me. Cheers, -Barry
On 12/28/2012 1:02 PM, Lennart Regebro wrote:
On Thu, Dec 20, 2012 at 5:43 PM, Barry Warsaw
mailto:barry@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 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
On 29/12/12 05:02, Lennart Regebro wrote:
On Thu, Dec 20, 2012 at 5:43 PM, Barry Warsaw
wrote: That would be `class UnknownTimeZoneError(ValueError, TimeZoneError)`.
As of today, in Pytz, UnknownTimeZoneError in fact subclasses KeyError. Any opinions against that?
The PEP says: * New 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.
In that case, can you rename UnknownTimeZoneError to TimeZoneError, which is shorter and easier to read, write and remember? (We have KeyError rather than UnknownKeyError, NameError rather than UnknownNameError, etc.) -- Steven
On Sat, Dec 29, 2012 at 2:23 AM, Steven D'Aprano
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. 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
On 29/12/12 15:40, Lennart Regebro wrote:
On Sat, Dec 29, 2012 at 2:23 AM, Steven D'Aprano
wrote: The PEP says:
* New function :``timezone(name=None, db_path=None)``
This function takes a name string that must be a string specifying a valid zoneinfo timezone, ie "US/Eastern", "Europe/Warsaw" or "Etc/GMT+11".
It 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 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. :-)
It means you want a time zone that doesn't exist in the database, which is 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. -- Steven
-----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 tseaver@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-----
On Sun, Dec 30, 2012 at 11:19 AM, Steven D'Aprano
If I've understood it correctly, that contradicts the PEP. One example given is "Etc/GMT+11", which is not a timezone *name*, but a timezone name *plus an offset*. Presumably if GMT+11 is legal, so should be GMT+10:30.
This 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_zoneshttp://en.wikipedia.org/wiki/List_of_tz_database_time_zones
It exists in the database files, http://www.iana.org/time-zones, the ``etcetera`` file.
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
participants (23)
-
Antoine Pitrou
-
Barry Warsaw
-
Ben Finney
-
Brandon W Maister
-
Brian Curtin
-
Christian Heimes
-
Christian Tismer
-
Dirkjan Ochtman
-
Donald Stufft
-
Glenn Linderman
-
Greg Ewing
-
Guido van Rossum
-
Janzert
-
Lennart Regebro
-
MRAB
-
Nick Coghlan
-
Paul Moore
-
Robert Brewer
-
Steve Dower
-
Steven D'Aprano
-
Terry Reedy
-
Tres Seaver
-
Éric Araujo