[Python-Dev] PEP-0431 update 4
Here is the update of PEP-0431. The major changes are that the new class now has a lowercase name, to conform to the rest of the datetime modeule: dsttimezone (i decided against dst_timezone, as non of the other classes have underscores). Also the timezone name sets are gone. Thanks to Nick Coghlan for finding a whole bunch of minor mistakes. //Lennart PEP: 431 Title: Time zone support improvements Version: $Revision$ Last-Modified: $Date$ Author: Lennart Regebro BDFL-Delegate: Barry Warsaw Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 11-Dec-2012 Post-History: 11-Dec-2012, 28-Dec-2012, 28-Jan-2013 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 outside of a tzinfo baseclass that supports fixed offsets. 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. Time zone 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 Unix and Unix-like operating systems, including OS X. This gives us the opportunity to include the code that supports the zoneinfo data in the standard library, but by default use the operating system's 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 zoneinfo database, for example Windows, the Python source distribution will include a copy of the zoneinfo database, and a distribution containing the latest zoneinfo database will 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 receiving updates and therefore have an outdated database. With such a mechanism Python would have full time zone support in the standard library on any platform, and a simple package installation would provide an updated time zone database on those platforms where the zoneinfo database isn't included, such as Windows, or on platforms where OS updates are no longer provided. The time zone support will be implemented by making the ``datetime`` module into a package, and adding time zone support to ``datetime`` 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 ambiguous 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 ``datetime`` module. For Windows it will look up the local Windows time zone name, and use a mapping between Windows time zone names and zoneinfo time zone names provided by the Unicode consortium to convert that to a zoneinfo time zone. The mapping should be updated before each major or bugfix release, scripts for doing so will be provided in the ``Tools/`` directory. Ambiguous times --- When changing over from daylight savings time (DST) the clock is turned back one hour. This means that the times during that hour happens twice, once with DST and then once without DST. Similarly, when changing to daylight savings time, one hour goes missing. The current time zone API can not differentiate 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, 10, 28, 2, 0, tzinfo=zonei
Re: [Python-Dev] cpython (2.7): - Issue #17086: Backport the patches from the 3.3 branch to cross-build
Le Wed, 6 Feb 2013 16:08:39 -0500, Barry Warsaw a écrit : > On Feb 06, 2013, at 02:38 PM, Antoine Pitrou wrote: > > >Le Mon, 04 Feb 2013 21:04:39 +0100, > >Matthias Klose a écrit : > >> So what I do understand, build-related issues like an arm64 or > >> mingw32 port are ok for 2.7, if they are stable on the trunk, and > >> communicated on python-dev? > > > >Making Python build on a new platform is, AFAICT, considered a new > >feature, not a bugfix. For example, we support new MSVC versions in > >the main development branch, not in bugfix branches. > > Except that 2.7 is an exception to that since it's the last of the > Python 2 series, and has a much longer lifespan than normal > releases. I'm pretty sure we agreed that there would be some > exceptions for issues like new platforms for 2.7. Well, apparently we didn't make such an exception for MSVC :-) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (2.7): - Issue #17086: Backport the patches from the 3.3 branch to cross-build
On 7 Feb 2013 19:13, "Antoine Pitrou" wrote: > > Le Wed, 6 Feb 2013 16:08:39 -0500, > Barry Warsaw a écrit : > > On Feb 06, 2013, at 02:38 PM, Antoine Pitrou wrote: > > > > >Le Mon, 04 Feb 2013 21:04:39 +0100, > > >Matthias Klose a écrit : > > >> So what I do understand, build-related issues like an arm64 or > > >> mingw32 port are ok for 2.7, if they are stable on the trunk, and > > >> communicated on python-dev? > > > > > >Making Python build on a new platform is, AFAICT, considered a new > > >feature, not a bugfix. For example, we support new MSVC versions in > > >the main development branch, not in bugfix branches. > > > > Except that 2.7 is an exception to that since it's the last of the > > Python 2 series, and has a much longer lifespan than normal > > releases. I'm pretty sure we agreed that there would be some > > exceptions for issues like new platforms for 2.7. > > Well, apparently we didn't make such an exception for MSVC :-) Python 2.7 still runs on Windows just fine, and changing the C runtime used is *not* purely a change to the build process (it effectively breaks the ABI). I'm not sure how you see that decision being remotely related to Benjamin's decision to allow the cross-compilation patches. Cheers, Nick. > > Regards > > Antoine. > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (2.7): - Issue #17086: Backport the patches from the 3.3 branch to cross-build
Le Thu, 7 Feb 2013 20:02:39 +1000, Nick Coghlan a écrit : > On 7 Feb 2013 19:13, "Antoine Pitrou" wrote: > > > > Le Wed, 6 Feb 2013 16:08:39 -0500, > > Barry Warsaw a écrit : > > > On Feb 06, 2013, at 02:38 PM, Antoine Pitrou wrote: > > > > > > >Le Mon, 04 Feb 2013 21:04:39 +0100, > > > >Matthias Klose a écrit : > > > >> So what I do understand, build-related issues like an arm64 or > > > >> mingw32 port are ok for 2.7, if they are stable on the trunk, > > > >> and communicated on python-dev? > > > > > > > >Making Python build on a new platform is, AFAICT, considered a > > > >new feature, not a bugfix. For example, we support new MSVC > > > >versions in the main development branch, not in bugfix branches. > > > > > > Except that 2.7 is an exception to that since it's the last of the > > > Python 2 series, and has a much longer lifespan than normal > > > releases. I'm pretty sure we agreed that there would be some > > > exceptions for issues like new platforms for 2.7. > > > > Well, apparently we didn't make such an exception for MSVC :-) > > Python 2.7 still runs on Windows just fine, and changing the C > runtime used is *not* purely a change to the build process (it > effectively breaks the ABI). There is a difference between supporting several MSVCs and changing the MSVC used for the official binary builds. People did ask us to support newer MSVCs. > I'm not sure how you see that decision being remotely related to > Benjamin's decision to allow the cross-compilation patches. I was merely replying to the idea that "we allow new build features in 2.7". Non-trivial build patches have a tendency to produce unexpected breakage (for the record, the initial cross-compiling commits on 3.x brought a lot of breakage at first). Our build system is complicated and *very* poorly documented, I am surprised you think it is a good idea to accept large changes in bugfix releases. I'm still of the advice that non-trivial build enhancements shouldn't be treated differently from any new feature. Patches for bugfix branches can be maintained externally, as they already are (e.g. by Linux distributions). (btw, nothing to do with this discussion, Nick, but it appears your RHEL buildbot is offline) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (2.7): - Issue #17086: Backport thepatches from the 3.3 branch to cross-build
> (btw, nothing to do with this discussion, Nick, but it appears your > RHEL buildbot is offline) > > Regards Btw rpm build and packaging can be done on the suse build service: it is a very complete (and free) service. https://build.opensuse.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyCon Tickets Almost Sold Out
On Wed, Feb 6, 2013 at 3:29 PM, Brian Curtin wrote: > Since the Language Summit is held at PyCon I think this counts as > on-topic... > > If you're interested in going to the conference, there are under 50 > tickets remaining: https://us.pycon.org/2013/registration/ ... and then there were none. Tutorials are still open, though. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyConTW is calling for proposals!
Hi, On Thu, 7 Feb 2013 23:33:46 +0800 LittleQ wrote: > > PyCon Taiwan is calling for proposals now, Python is becoming one of famous > programming languages in Taiwan, We need every Python developers' > participating. Go to the link above, and submit your proposal right now! :D > > Feel free to send me an email if you have any question. > > Have a nice Day, > > Colin, PR @ PyConTW > > (if this mail is not appropriate on this mailing list (python-dev), just > let me know, then I won't bother everybody anymore, thanks.) It sounds totally legitimate to me. cheers Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
