PEP 431 Time zone support improvements - Update
Happy Holidays! Here is the update of PEP 431 with the changes that emerged
after the earlier discussion.
A raw download is here:
https://raw.github.com/regebro/tz-pep/master/pep-04tz.txt
PEP: 431
Title: Time zone support improvements
Version: $Revision$
Last-Modified: $Date$
Author: Lennart Regebro
On 28 Dec, 2012, at 21:23, Lennart Regebro
Happy Holidays! Here is the update of PEP 431 with the changes that emerged after the earlier discussion.
Why is the new timezone support added in a submodule of datetime? Adding the new function and exception to datetime itself wouldn't clutter the API that much, and datetime already contains some timezone support (datetime.tzinfo). Ronald
On Fri, Dec 28, 2012 at 10:12 PM, Ronald Oussoren
On 28 Dec, 2012, at 21:23, Lennart Regebro
wrote: Happy Holidays! Here is the update of PEP 431 with the changes that emerged after the earlier discussion.
Why is the new timezone support added in a submodule of datetime?
Because several people wanted it that way and nobody objected.
Adding the new function and exception to datetime itself wouldn't clutter the API that much
It will make the datetime.py twice as long though, and the second longest module in the stdlib, beaten only by decimal.py. Perhaps this is not a problem. //Lennart
On Sat, Dec 29, 2012 at 6:23 AM, Lennart Regebro
Happy Holidays! Here is the update of PEP 431 with the changes that emerged after the earlier discussion.
A raw download is here: https://raw.github.com/regebro/tz-pep/master/pep-04tz.txt
For UI purposes, "pytz" has some helpers to get lists of timezone names (all, common and country specific): http://pytz.sourceforge.net/#helpers Is there a specific reason you chose to exclude those from the PEP?
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'm still a fan of *always* shipping fallback tzdata, regardless of platform. The stdlib would then look in three places for timezone data when datetime.timezone was first imported: 1. the "tzdata-update" database 2. the OS provided database 3. the fallback database Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Sat, 29 Dec 2012 16:00:39 +1000
Nick Coghlan
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'm still a fan of *always* shipping fallback tzdata, regardless of platform. The stdlib would then look in three places for timezone data when datetime.timezone was first imported:
1. the "tzdata-update" database 2. the OS provided database 3. the fallback database
+1 ! Regards Antoine.
On Sat, Dec 29, 2012 at 11:45 AM, Antoine Pitrou
I'm still a fan of *always* shipping fallback tzdata, regardless of platform. The stdlib would then look in three places for timezone data when datetime.timezone was first imported:
1. the "tzdata-update" database 2. the OS provided database 3. the fallback database
+1 !
Yeah, from me as well. Cheers, Dirkjan
On Sat, Dec 29, 2012 at 7:00 AM, Nick Coghlan
On Sat, Dec 29, 2012 at 6:23 AM, Lennart Regebro
wrote: Happy Holidays! Here is the update of PEP 431 with the changes that emerged after the earlier discussion.
A raw download is here: https://raw.github.com/regebro/tz-pep/master/pep-04tz.txt
For UI purposes, "pytz" has some helpers to get lists of timezone names (all, common and country specific): http://pytz.sourceforge.net/#helpers
Funnily enough, I woke up this morning thinking that this should be added, and wondering why pytz didn't have such lists. So I just missed (or rather forgot) that they existed. I'll add them. Is there a specific reason you chose to exclude those from the PEP?
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'm still a fan of *always* shipping fallback tzdata
Yes, and I did update the rest of the PEP with this, but I missed the discussion part. //Lennart
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/29/2012 01:00 AM, Nick Coghlan wrote:
I'm still a fan of *always* shipping fallback tzdata, regardless of platform. The stdlib would then look in three places for timezone data when datetime.timezone was first imported:
1. the "tzdata-update" database 2. the OS provided database 3. the fallback database
- -Lots for enabling fallback by default except on platforms known not to have their own database, or given some explicit 'siteconfigure.py'-like knob enabling it. A clean error is better than a bad-but-silent answer. 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/ iEYEARECAAYFAlDfOMEACgkQ+gerLs4ltQ7mfQCgxV13Ch7eW/yDwCPMfEebeNuY xr0An1yvuUkVUQGY8nKDt9GxemdLlHMA =JtY0 -----END PGP SIGNATURE-----
On Sat, Dec 29, 2012 at 7:38 PM, Tres Seaver
- -Lots for enabling fallback by default except on platforms known not to have their own database
Well, it's the same thing really. If the platform does have a database, the fallback will not be used. Of course, there is the case of the database existing on the platform normally, but somebody for some reason deleting the files, but I don't think that case deserves an error message. I also expect that most platform distributions, such as for Ubuntu, will not include the fallback database, as it will never be used. I'll add something about that and that we need to raise an error of some sort (any opinions on what?) if no database is found at all. //Lennart
On Sat, Dec 29, 2012 at 7:54 PM, Lennart Regebro
On Sat, Dec 29, 2012 at 7:38 PM, Tres Seaver
wrote: - -Lots for enabling fallback by default except on platforms known not to have their own database
Well, it's the same thing really. If the platform does have a database, the fallback will not be used. Of course, there is the case of the database existing on the platform normally, but somebody for some reason deleting the files, but I don't think that case deserves an error message.
I also expect that most platform distributions, such as for Ubuntu, will not include the fallback database, as it will never be used. I'll add something about that and that we need to raise an error of some sort (any opinions on what?) if no database is found at all.
Actually I already added that, but opinions on what error to raise are still welcome. Currently it says: 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 ``tzdata-update`` package.
On Sat, 29 Dec 2012 19:56:43 +0100
Lennart Regebro
On Sat, Dec 29, 2012 at 7:54 PM, Lennart Regebro
wrote: On Sat, Dec 29, 2012 at 7:38 PM, Tres Seaver
wrote: - -Lots for enabling fallback by default except on platforms known not to have their own database
Well, it's the same thing really. If the platform does have a database, the fallback will not be used. Of course, there is the case of the database existing on the platform normally, but somebody for some reason deleting the files, but I don't think that case deserves an error message.
I also expect that most platform distributions, such as for Ubuntu, will not include the fallback database, as it will never be used. I'll add something about that and that we need to raise an error of some sort (any opinions on what?) if no database is found at all.
Actually I already added that, but opinions on what error to raise are still welcome. Currently it says:
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 ``tzdata-update`` package.
Why should we care about that situation if we *do* provide a database? Distributions can decide to exclude some files from their packages, but it's their problem, not ours. Regards Antoine.
2012-12-29 19:54:42 Lennart Regebro napisał(a):
On Sat, Dec 29, 2012 at 7:38 PM, Tres Seaver
wrote: - -Lots for enabling fallback by default except on platforms known not to have their own database
Well, it's the same thing really. If the platform does have a database, the fallback will not be used.
I suggest that configure script support --enable-internal-timezone-database / --disable-internal-timezone-database options. --disable-internal-timezone-database should cause that installational targets in Makefile would not install files of timezone database. -- Arfrever Frehtes Taifersar Arahesis
On Sat, Dec 29, 2012 at 8:04 PM, Antoine Pitrou
On Sat, Dec 29, 2012 at 7:54 PM, Lennart Regebro
wrote: On Sat, Dec 29, 2012 at 7:38 PM, Tres Seaver
- -Lots for enabling fallback by default except on platforms known not to have their own database
Well, it's the same thing really. If the platform does have a database, the fallback will not be used. Of course, there is the case of the database existing on the platform normally, but somebody for some reason deleting the files, but I don't think that case deserves an error message.
I also expect that most platform distributions, such as for Ubuntu, will not include the fallback database, as it will never be used. I'll add something about that and that we need to raise an error of some sort (any opinions on what?) if no database is found at all.
Actually I already added that, but opinions on what error to raise are still welcome. Currently it says:
If no database is found an ``UnknownTimeZoneError`` or subclass
On Sat, 29 Dec 2012 19:56:43 +0100 Lennart Regebro
wrote: thereof will be raised with a message explaining that no zoneinfo database can be found, but that you can install one with the ``tzdata-update`` package.
Why should we care about that situation if we *do* provide a database? Distributions can decide to exclude some files from their packages, but it's their problem, not ours.
Yes, but a comprehensible error message is useful even if somebody messed up the system/configuration. //Lennart
On 29Dec2012 21:16, Lennart Regebro
On Sat, Dec 29, 2012 at 11:55 PM, Cameron Simpson
On 29Dec2012 21:16, Lennart Regebro
wrote: | On Sat, Dec 29, 2012 at 8:04 PM, Antoine Pitrou wrote: | > Why should we care about that situation if we *do* provide a database? | > Distributions can decide to exclude some files from their packages, but | > it's their problem, not ours. | | Yes, but a comprehensible error message is useful even if somebody messed | up the system/configuration. Couldn't you just agree to augument the exception with some "I looked here, there and there" information. It avoids a lot of bikeshedding and makes things clear. You're not diagnosing system misconfiguration, just saying "I can't find stuff, and here is where I looked".
Since the location of the tzdata-update package isn't a fixed place it's hard to say "I looked here, there and there", though. I don't think anyone has suggested making any diagnostics. :-) //Lennart
On Sat, Dec 29, 2012 at 11:59 PM, Terry Reedy
On 12/29/2012 3:16 PM, Lennart Regebro wrote:
Yes, but a comprehensible error message is useful even if somebody
messed up the system/configuration.
Just reuse whatever exception type you create and add a sensible message. Hopefully, it will never be seen.
I haven't implemented this, but I suspect the code will in the end look for the tzdata module, which means that if it doesn't exist, the error raised is an ImportError. //Lennart
On 30Dec2012 07:42, Lennart Regebro
On 29 Dec, 2012, at 5:48, Lennart Regebro
On Fri, Dec 28, 2012 at 10:12 PM, Ronald Oussoren
wrote: On 28 Dec, 2012, at 21:23, Lennart Regebro
wrote: Happy Holidays! Here is the update of PEP 431 with the changes that emerged after the earlier discussion.
Why is the new timezone support added in a submodule of datetime?
Because several people wanted it that way and nobody objected.
Adding the new function and exception to datetime itself wouldn't clutter the API that much
It will make the datetime.py twice as long though, and the second longest module in the stdlib, beaten only by decimal.py. Perhaps this is not a problem.
The module could be split into several modules in a package without affecting the public API if that would help with maintenance, simular to unittest. Ronald
On 30/12/12 07:16, Lennart Regebro wrote:
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 ``tzdata-update`` package.
Why should we care about that situation if we *do* provide a database? Distributions can decide to exclude some files from their packages, but it's their problem, not ours.
Yes, but a comprehensible error message is useful even if somebody messed up the system/configuration.
+1 -- Steven
On Sun, Dec 30, 2012 at 10:47 AM, Ronald Oussoren
The module could be split into several modules in a package without affecting the public API if that would help with maintenance, simular to unittest.
This is of course true. Maybe that is a good idea. //Lennart
On Sat, Dec 29, 2012 at 8:05 PM, Arfrever Frehtes Taifersar Arahesis < arfrever.fta@gmail.com> wrote:
On Sat, Dec 29, 2012 at 7:38 PM, Tres Seaver
wrote: - -Lots for enabling fallback by default except on platforms known not to have their own database
Well, it's the same thing really. If the platform does have a database,
2012-12-29 19:54:42 Lennart Regebro napisał(a): the
fallback will not be used.
I suggest that configure script support --enable-internal-timezone-database / --disable-internal-timezone-database options. --disable-internal-timezone-database should cause that installational targets in Makefile would not install files of timezone database.
Will this help the makers of distributions, like Ubuntu etc? If that is the case, then it might be worth doing, otherwise I don't think it's very useful. //Lennart
On Sun, Dec 30, 2012 at 10:47 AM, Ronald Oussoren
The module could be split into several modules in a package without affecting the public API if that would help with maintenance, simular to unittest.
Is there popular support for doing so, ie make datetime into a package, have all of the pytz modules in there, but letting the public API go only through datetime, ie no timezone submodule? If the list decides so, I'll update the PEP. //Lennart
On Mon, Jan 7, 2013 at 12:01 PM, Lennart Regebro
On Sun, Dec 30, 2012 at 10:47 AM, Ronald Oussoren
wrote: The module could be split into several modules in a package without affecting the public API if that would help with maintenance, simular to unittest.
Is there popular support for doing so, ie make datetime into a package, have all of the pytz modules in there, but letting the public API go only through datetime, ie no timezone submodule?
If the list decides so, I'll update the PEP.
+1 for putting this under datetime; "Namespaces are one honking great idea". People looking for date stuff is going to look in datetime or time first so might as well put it there to begin with.
On Fri, Dec 28, 2012 at 10:12 PM, Ronald Oussoren
On 28 Dec, 2012, at 21:23, Lennart Regebro
wrote: Happy Holidays! Here is the update of PEP 431 with the changes that emerged after the earlier discussion.
Why is the new timezone support added in a submodule of datetime? Adding the new function and exception to datetime itself wouldn't clutter the API that much, and datetime already contains some timezone support (datetime.tzinfo).
Putting the API directly into the datetime module does conflict with the new timezone class from Python 3.2. The timezone() function therefore needs to be called something else, or the timezone class must be renamed. Alternative names for the timezone() function is get_timezone(), which has already been rejected, and zoneinfo() which makes it clear that it's only zoneinfo timezones that are relevant. Or the timezone class get's renamed TimeZone (which is more PEP8 anyway). We can allow the timezone() function to take both timezone(offset, [name]) as now, and timezone(name) and return a TimeZone object in the first case and a zoneinfo based timezone in the second case. Or maybe somebody else can come up with more clever options?
On Tue, Jan 8, 2013 at 1:08 PM, Lennart Regebro
On Fri, Dec 28, 2012 at 10:12 PM, Ronald Oussoren
wrote: On 28 Dec, 2012, at 21:23, Lennart Regebro
wrote: Happy Holidays! Here is the update of PEP 431 with the changes that emerged after the earlier discussion.
Why is the new timezone support added in a submodule of datetime? Adding the new function and exception to datetime itself wouldn't clutter the API that much, and datetime already contains some timezone support (datetime.tzinfo).
Putting the API directly into the datetime module does conflict with the new timezone class from Python 3.2. The timezone() function therefore needs to be called something else, or the timezone class must be renamed.
Can't rename the class since that would potentially break code (e.g. if the class can be pickled).
Alternative names for the timezone() function is get_timezone(), which has already been rejected, and zoneinfo() which makes it clear that it's only zoneinfo timezones that are relevant.
I'm personally +0 on zoneinfo(), but I don't have a better suggestion. -Brett
Or the timezone class get's renamed TimeZone (which is more PEP8 anyway).
We can allow the timezone() function to take both timezone(offset, [name]) as now, and timezone(name) and return a TimeZone object in the first case and a zoneinfo based timezone in the second case.
Or maybe somebody else can come up with more clever options?
_______________________________________________ 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/brett%40python.org
On Wed, Jan 9, 2013 at 5:02 AM, Brett Cannon
On Tue, Jan 8, 2013 at 1:08 PM, Lennart Regebro
wrote: Alternative names for the timezone() function is get_timezone(), which has already been rejected, and zoneinfo() which makes it clear that it's only zoneinfo timezones that are relevant.
I'm personally +0 on zoneinfo(), but I don't have a better suggestion.
zoneinfo() sounds reasonable to me. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (13)
-
Alexander Belopolsky
-
Antoine Pitrou
-
Arfrever Frehtes Taifersar Arahesis
-
Benjamin Peterson
-
Brett Cannon
-
Cameron Simpson
-
Dirkjan Ochtman
-
Lennart Regebro
-
Nick Coghlan
-
Ronald Oussoren
-
Steven D'Aprano
-
Terry Reedy
-
Tres Seaver