On Thu, Feb 18, 2010 at 11:29, Stuart Bishop <stu...@stuartbishop.net> wrote: > I think a tzinfo implementation in the standard library that uses the system > timezone database would be useful to a great many people, providing a > standard way of mapping a string to a tzinfo instance.
Well, that wouldn't work on Windows, which would be a bit strange. So yes, on some systems it would mean you now have pytz in the standard library, while you don't on others. That's going to cause problems, while it doesn't actually solve any problem except "I need to install pytz", which isn't much of a problem. > The number of > frameworks requiring pytz as a dependency demonstrate this. They are going to still need to require pytz, or rather the data part of it. > It is unfortunate that those strings would be platform specific. For most > applications this doesn't matter - you are reading the key from a config > file or allowing the user to select from a list of possible values. Well, the problem in finding your won timezone has been documented in one of the links I sent before. But that's another problems, solved by the tzfile/tzwin implementations discussed previously. > As the pytz maintainer, this would help me solve a long standing problem. > Currently, pytz tzinfo instances don't really follow the documented tzinfo > interface (in order to allow localized datetime arithmetic to be always > correct instead of good enough). This is a source of confusion to many users > who don't need this level of accuracy. It would be great if the standard > library provided a tzinfo implementation that was good enough for the vast > majority of users, and for people who do care they can continue to use > pytz.timezone() to retrieve the anal tzinfo implementation. Users will be > happier as they will have fewer bugs in their code. The alternative for me > is to eventually split pytz, somehow providing the simpler interface that > works exactly as documented in the Python reference and the anal interface > that works per the pytz README (in hindsight, it should have been this way > from day 1). I understand the need for different API's but can't the extended part that doesn't behave like timezone be separate methods? I don't *mind* pytz in the standardlibrary, I just don't really see how it solves any problems, while I can see how it creates them. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 _______________________________________________ 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
