Earlier this year

• May 14, 2009

  issue 16 (Pinned pytz dependency causes problems with current Pinax bu...) commented on by rkirmizi   -   sudo easy_install --upgrade pytz worked 4 me well :)

  sudo easy_install --upgrade pytz worked 4 me well :)
• Mar 29, 2009

  issue 16 (Pinned pytz dependency causes problems with current Pinax bu...) reported by dan.fairs   -   Trunk django-timezones has an explicit dependency on pytz 2009a. A current buildout using the buildout.cfg in Pinax trunk gives the following error while installing django-timezones: VersionConflict: (pytz 2009d (/Users/dan/opt/virtual/2.5/pinax/lib/python2.5/site-packages), Requirement.parse('pytz==2009a')) Could the dependency be modified to be pytz>=2009a?

  Trunk django-timezones has an explicit dependency on pytz 2009a. A current buildout using the buildout.cfg in Pinax trunk gives the following error while installing django-timezones: VersionConflict: (pytz 2009d (/Users/dan/opt/virtual/2.5/pinax/lib/python2.5/site-packages), Requirement.parse('pytz==2009a')) Could the dependency be modified to be pytz>=2009a?
• Mar 04, 2009

  issue 15 (LocalizedDateTimeField does not work with null values) reported by lim.ck.michael   -   What steps will reproduce the problem? 1. Create a model that accepts LocalizedDateTimeField(null=True) 2. Try to create a new object What is the expected output? What do you see instead? Assuming this model has been defined: class FooBar(models.Model): value = models.IntegerField() date = LocalizedDateTimeField(null=True) >>> FooBar.objects.create(value=3) Traceback (most recent call last): File "<console>", line 1, in <module> File "django/db/models/manager.py", line 99, in create return self.get_query_set().create(**kwargs) File "django/db/models/query.py", line 318, in create obj = self.model(**kwargs) File "django/db/models/base.py", line 255, in __init__ setattr(self, field.attname, val) File "django/src/apps/external_apps/timezones/fields.py", line 100, in set_dtz_field if dt.tzinfo is None: AttributeError: 'NoneType' object has no attribute 'tzinfo' Please provide any additional information below. The patch handles the getting and setting of Null values of LocalizedDateTimeField.

  What steps will reproduce the problem? 1. Create a model that accepts LocalizedDateTimeField(null=True) 2. Try to create a new object What is the expected output? What do you see instead? Assuming this model has been defined: class FooBar(models.Model): value = models.IntegerField() date = LocalizedDateTimeField(null=True) >>> FooBar.objects.create(value=3) Traceback (most recent call last): File "<console>", line 1, in <module> File "django/db/models/manager.py", line 99, in create return self.get_query_set().create(**kwargs) File "django/db/models/query.py", line 318, in create obj = self.model(**kwargs) File "django/db/models/base.py", line 255, in __init__ setattr(self, field.attname, val) File "django/src/apps/external_apps/timezones/fields.py", line 100, in set_dtz_field if dt.tzinfo is None: AttributeError: 'NoneType' object has no attribute 'tzinfo' Please provide any additional information below. The patch handles the getting and setting of Null values of LocalizedDateTimeField.
• Feb 17, 2009

  issue 14 (IOError: [Errno 2] No such file or directory: '/usr/share/zo...) Status changed by brosner   -   Great. I figured this was the case. I'll be sure keep this in mind as it pops up again. I am currently targeting 2009a in setup.py.

  Status: Invalid

  Great. I figured this was the case. I'll be sure keep this in mind as it pops up again. I am currently targeting 2009a in setup.py.

  Status: Invalid
• Feb 17, 2009

  issue 14 (IOError: [Errno 2] No such file or directory: '/usr/share/zo...) commented on by jonas.esp   -   I had pytz 2008b, and it's fixed updating it: easy_install -U pytz

  I had pytz 2008b, and it's fixed updating it: easy_install -U pytz
• Feb 09, 2009

  issue 14 (IOError: [Errno 2] No such file or directory: '/usr/share/zo...) commented on by t...@caktusgroup.com   -   I'm using Python 2.5.2 and pytz 2008b

  I'm using Python 2.5.2 and pytz 2008b
• Feb 09, 2009

  issue 14 (IOError: [Errno 2] No such file or directory: '/usr/share/zo...) commented on by halbkarat   -   Same error: user@prometheus:~/workspace/django/django-sites/testsite$ ./manage.py validate Traceback (most recent call last): File "./manage.py", line 11, in <module> execute_manager(settings) File "/home/user/workspace/django/django-sites/testsite/__init__.py", line 340, in execute_manager File "/home/user/workspace/django/django-sites/testsite/__init__.py", line 295, in execute File "/usr/lib/python2.5/site-packages/django/core/management/base.py", line 195, in run_from_argv File "/usr/lib/python2.5/site-packages/django/core/management/base.py", line 222, in execute File "/usr/lib/python2.5/site-packages/django/core/management/base.py", line 351, in handle File "/var/lib/python-support/python2.5/validate.py", line 9, in handle_noargs # http://www.voidspace.org.uk/python/license.shtml File "/usr/lib/python2.5/site-packages/django/core/management/base.py", line 249, in validate File "/usr/lib/python2.5/site-packages/django/core/management/validation.py", line 28, in get_validation_errors File "/usr/lib/python2.5/site-packages/django/db/models/loading.py", line 128, in get_app_errors File "/usr/lib/python2.5/site-packages/django/db/models/loading.py", line 57, in _populate File "/usr/lib/python2.5/site-packages/django/db/models/loading.py", line 72, in load_app File "/usr/local/lib/python2.5/site-packages/profiles/models.py", line 9, in <module> from timezones.fields import TimeZoneField File "/usr/local/lib/python2.5/site-packages/timezones/fields.py", line 7, in <module> from timezones import forms File "/usr/local/lib/python2.5/site-packages/timezones/forms.py", line 14, in <module> now = datetime.datetime.now(pytz.timezone(tz)) File "/usr/lib/python2.5/site-packages/pytz/__init__.py", line 136, in timezone _tzinfo_cache[zone] = build_tzinfo(zone, open_resource(zone)) File "/usr/lib/python2.5/site-packages/pytz/__init__.py", line 54, in open_resource return open(filename, 'rb') IOError: [Errno 2] No such file or directory: '/usr/share/zoneinfo/US/Pacific-New' user@prometheus:~/workspace/django/django-sites/testsite$ My host runs on Debian Testing with debian-packages "python 2.5.2-3" and "python-tz 2008c-2" installed. Django revision: 9646. I've just upgraded django-timezones from r35 a few minutes ago... P.S.: Python on Debian Stable is 2.4.4-2 and python-tz 2006p-0.1 - in case someone asks me for minimum requirements and backward compability...

  Same error: user@prometheus:~/workspace/django/django-sites/testsite$ ./manage.py validate Traceback (most recent call last): File "./manage.py", line 11, in <module> execute_manager(settings) File "/home/user/workspace/django/django-sites/testsite/__init__.py", line 340, in execute_manager File "/home/user/workspace/django/django-sites/testsite/__init__.py", line 295, in execute File "/usr/lib/python2.5/site-packages/django/core/management/base.py", line 195, in run_from_argv File "/usr/lib/python2.5/site-packages/django/core/management/base.py", line 222, in execute File "/usr/lib/python2.5/site-packages/django/core/management/base.py", line 351, in handle File "/var/lib/python-support/python2.5/validate.py", line 9, in handle_noargs # http://www.voidspace.org.uk/python/license.shtml File "/usr/lib/python2.5/site-packages/django/core/management/base.py", line 249, in validate File "/usr/lib/python2.5/site-packages/django/core/management/validation.py", line 28, in get_validation_errors File "/usr/lib/python2.5/site-packages/django/db/models/loading.py", line 128, in get_app_errors File "/usr/lib/python2.5/site-packages/django/db/models/loading.py", line 57, in _populate File "/usr/lib/python2.5/site-packages/django/db/models/loading.py", line 72, in load_app File "/usr/local/lib/python2.5/site-packages/profiles/models.py", line 9, in <module> from timezones.fields import TimeZoneField File "/usr/local/lib/python2.5/site-packages/timezones/fields.py", line 7, in <module> from timezones import forms File "/usr/local/lib/python2.5/site-packages/timezones/forms.py", line 14, in <module> now = datetime.datetime.now(pytz.timezone(tz)) File "/usr/lib/python2.5/site-packages/pytz/__init__.py", line 136, in timezone _tzinfo_cache[zone] = build_tzinfo(zone, open_resource(zone)) File "/usr/lib/python2.5/site-packages/pytz/__init__.py", line 54, in open_resource return open(filename, 'rb') IOError: [Errno 2] No such file or directory: '/usr/share/zoneinfo/US/Pacific-New' user@prometheus:~/workspace/django/django-sites/testsite$ My host runs on Debian Testing with debian-packages "python 2.5.2-3" and "python-tz 2008c-2" installed. Django revision: 9646. I've just upgraded django-timezones from r35 a few minutes ago... P.S.: Python on Debian Stable is 2.4.4-2 and python-tz 2006p-0.1 - in case someone asks me for minimum requirements and backward compability...
• Feb 09, 2009

  r45 (Use setuptools and updated the pytz dependancy.) committed by brosner   -   Use setuptools and updated the pytz dependancy.

  Use setuptools and updated the pytz dependancy.
• Feb 09, 2009

  issue 12 (Bad assertion) Status changed by brosner   -  

  Status: Accepted

  Status: Accepted
• Feb 09, 2009

  issue 14 (IOError: [Errno 2] No such file or directory: '/usr/share/zo...) commented on by brosner   -   What version of pytz are you running? I believe I saw this with an older version. I'd like to catch this now and determine what version to work with.

  What version of pytz are you running? I believe I saw this with an older version. I'd like to catch this now and determine what version to work with.
• Feb 06, 2009

  issue 14 (IOError: [Errno 2] No such file or directory: '/usr/share/zo...) reported by t...@caktusgroup.com   -   What steps will reproduce the problem? 1. ./manage.py <anything> Traceback (most recent call last): File "./manage.py", line 11, in <module> execute_manager(settings) File "/home/tobias/caktus/eclipse-workspace/eeap/django/core/management/__init__.py", line 347, in execute_manager utility.execute() File "/home/tobias/caktus/eclipse-workspace/eeap/django/core/management/__init__.py", line 295, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/home/tobias/caktus/eclipse-workspace/eeap/django/core/management/base.py", line 195, in run_from_argv self.execute(*args, **options.__dict__) File "/home/tobias/caktus/eclipse-workspace/eeap/django/core/management/base.py", line 221, in execute self.validate() File "/home/tobias/caktus/eclipse-workspace/eeap/django/core/management/base.py", line 249, in validate num_errors = get_validation_errors(s, app) File "/home/tobias/caktus/eclipse-workspace/eeap/django/core/management/validation.py", line 28, in get_validation_errors for (app_name, error) in get_app_errors().items(): File "/home/tobias/caktus/eclipse-workspace/eeap/django/db/models/loading.py", line 128, in get_app_errors self._populate() File "/home/tobias/caktus/eclipse-workspace/eeap/django/db/models/loading.py", line 57, in _populate self.load_app(app_name, True) File "/home/tobias/caktus/eclipse-workspace/eeap/django/db/models/loading.py", line 72, in load_app mod = __import__(app_name, {}, {}, ['models']) File "/home/tobias/caktus/eclipse-workspace/eeap/datalogger/models.py", line 5, in <module> from timezones.fields import TimeZoneField, LocalizedDateTimeField File "/home/tobias/caktus/eclipse-workspace/eeap/timezones/fields.py", line 7, in <module> from timezones import forms File "/home/tobias/caktus/eclipse-workspace/eeap/timezones/forms.py", line 14, in <module> now = datetime.datetime.now(pytz.timezone(tz)) File "/usr/lib/python2.5/site-packages/pytz/__init__.py", line 136, in timezone _tzinfo_cache[zone] = build_tzinfo(zone, open_resource(zone)) File "/usr/lib/python2.5/site-packages/pytz/__init__.py", line 54, in open_resource return open(filename, 'rb') IOError: [Errno 2] No such file or directory: '/usr/share/zoneinfo/US/Pacific-New' Just catch the exception when building PRETTY_TIMEZONE_CHOICES and ignore the time zone if it doesn't exist. See attached patch.

  What steps will reproduce the problem? 1. ./manage.py <anything> Traceback (most recent call last): File "./manage.py", line 11, in <module> execute_manager(settings) File "/home/tobias/caktus/eclipse-workspace/eeap/django/core/management/__init__.py", line 347, in execute_manager utility.execute() File "/home/tobias/caktus/eclipse-workspace/eeap/django/core/management/__init__.py", line 295, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/home/tobias/caktus/eclipse-workspace/eeap/django/core/management/base.py", line 195, in run_from_argv self.execute(*args, **options.__dict__) File "/home/tobias/caktus/eclipse-workspace/eeap/django/core/management/base.py", line 221, in execute self.validate() File "/home/tobias/caktus/eclipse-workspace/eeap/django/core/management/base.py", line 249, in validate num_errors = get_validation_errors(s, app) File "/home/tobias/caktus/eclipse-workspace/eeap/django/core/management/validation.py", line 28, in get_validation_errors for (app_name, error) in get_app_errors().items(): File "/home/tobias/caktus/eclipse-workspace/eeap/django/db/models/loading.py", line 128, in get_app_errors self._populate() File "/home/tobias/caktus/eclipse-workspace/eeap/django/db/models/loading.py", line 57, in _populate self.load_app(app_name, True) File "/home/tobias/caktus/eclipse-workspace/eeap/django/db/models/loading.py", line 72, in load_app mod = __import__(app_name, {}, {}, ['models']) File "/home/tobias/caktus/eclipse-workspace/eeap/datalogger/models.py", line 5, in <module> from timezones.fields import TimeZoneField, LocalizedDateTimeField File "/home/tobias/caktus/eclipse-workspace/eeap/timezones/fields.py", line 7, in <module> from timezones import forms File "/home/tobias/caktus/eclipse-workspace/eeap/timezones/forms.py", line 14, in <module> now = datetime.datetime.now(pytz.timezone(tz)) File "/usr/lib/python2.5/site-packages/pytz/__init__.py", line 136, in timezone _tzinfo_cache[zone] = build_tzinfo(zone, open_resource(zone)) File "/usr/lib/python2.5/site-packages/pytz/__init__.py", line 54, in open_resource return open(filename, 'rb') IOError: [Errno 2] No such file or directory: '/usr/share/zoneinfo/US/Pacific-New' Just catch the exception when building PRETTY_TIMEZONE_CHOICES and ignore the time zone if it doesn't exist. See attached patch.
• Feb 06, 2009

  issue 13 (LocalizedDateTimeField doesn't accept input in type other th...) reported by t...@caktusgroup.com   -   What steps will reproduce the problem? 1. foo = MyModel.objects.get(pk=1) 2. foo.date = '2008-01-01' 3. 'str' object has no attribute 'tzinfo' (or something like that) This works fine with a regular DateTimeField. The fix is to call to_python on the input before the tzinfo attribute is accessed. See attached patch.

  What steps will reproduce the problem? 1. foo = MyModel.objects.get(pk=1) 2. foo.date = '2008-01-01' 3. 'str' object has no attribute 'tzinfo' (or something like that) This works fine with a regular DateTimeField. The fix is to call to_python on the input before the tzinfo attribute is accessed. See attached patch.
• Feb 04, 2009

  issue 12 (Bad assertion) reported by ionel.mc   -   timezones\fields.py:15: SyntaxWarning: assertion is always true, perhaps remove parentheses? assert(reduce(lambda x, y: x and (len(y) <= MAX_TIMEZONE_LENGTH),

  timezones\fields.py:15: SyntaxWarning: assertion is always true, perhaps remove parentheses? assert(reduce(lambda x, y: x and (len(y) <= MAX_TIMEZONE_LENGTH),
• Feb 03, 2009

  issue 9 (TimeZoneField and LocalizedTimeZone should use the django.db...) Status changed by brosner   -   I saw #10 before this one. I will implement this when I fix #10. Thanks!

  Status: Accepted

  I saw #10 before this one. I will implement this when I fix #10. Thanks!

  Status: Accepted
• Feb 03, 2009

  issue 10 (Refactoring the LocalizedDateTimeField property descriptor b...) Status changed by brosner   -   Awesome! Thanks for your work. I'll take a look at the patch tomorrow morning :)

  Status: Accepted

  Awesome! Thanks for your work. I'll take a look at the patch tomorrow morning :)

  Status: Accepted
• Jan 04, 2009

  r44 (Added a description and long_description to setup.py.) committed by brosner   -   Added a description and long_description to setup.py.

  Added a description and long_description to setup.py.
• Jan 04, 2009

  r43 (Added a README.) committed by brosner   -   Added a README.

  Added a README.
• Jan 04, 2009

  r42 (Added version information.) committed by brosner   -   Added version information.

  Added version information.

Older

• Dec 29, 2008

  issue 10 (Refactoring the LocalizedDateTimeField property descriptor b...) reported by tamas.kemenczy   -   This package is looking good, thanks for the work! There were a couple of exceptions I encountered: - When using LocalizedDateTimeField where the value can be null, an exception is thrown (NoneType has no attribute 'tzinfo'). Localizing the field should only happen when it has a datetime value. - There is a function closure problem in the signal handler function as it iterates over all fields of a class. The closure keeps a reference to the last field in the iteration, which may not be the LocalizedDateTimeField object that is expected to be closed. - Using other fields of a model instance for obtaining the timezone, i.e. A model that a LocalizedDateTimeField that is to use a TimeZoneField on the same model instance. The current system depends on the model existing on the database. It would be nice to implement a solution which uses the model instance itself to avoid hitting the database and to use up-to-date field values not yet saved to the database. The patch I've included should fix these issues. An outline of the differences: - Using the descriptor protocol used in django.db.models.fields.subclassing. TimeZoneField uses the SubfieldBase metaclass. For LocalizedDateTimeField, instead of hooking into a signal I'm using a custom property descriptor and the `contribute_to_class` field method to provide the same functionality (doesn't need to use SubfieldBase in this case). This is related to issue 9. - The `timezone` keyword argument of the LocalizedDateTime field either accepts a string of a timezone name, a `datetime.tzinfo` subclass itself, or a callable which returns either of these types, but doesn't implicitly handle a query lookup. This implementation passes the model instance as the sole argument to the callable (if the callable expects it). So this provides a generic and more explicit entry point to do any variation of db lookup or just direct model instance attribute access:: class MyModel(models.Model): posted = LocalizedDateTimeField(timezone=lambda i: i.tz) tz = TimeZoneField() - The datetime localization happens on the LocalizedDateTimeField property getter instead of the setter. This is to ensure that the callable gets a fully initialized model instance passed to it. When a model instance is initialized from the db, or directly from python code via the constructor, not all field values might have been set on the model instance by the time a LocalizedDateTimeField is set. So for example, a corresponding TimeZoneField might not have been initialized until after the LocalizedDateTimeField is initialized. The localized datetime object is cached on the first property access, and the cached value is cleared when the property is set.

  This package is looking good, thanks for the work! There were a couple of exceptions I encountered: - When using LocalizedDateTimeField where the value can be null, an exception is thrown (NoneType has no attribute 'tzinfo'). Localizing the field should only happen when it has a datetime value. - There is a function closure problem in the signal handler function as it iterates over all fields of a class. The closure keeps a reference to the last field in the iteration, which may not be the LocalizedDateTimeField object that is expected to be closed. - Using other fields of a model instance for obtaining the timezone, i.e. A model that a LocalizedDateTimeField that is to use a TimeZoneField on the same model instance. The current system depends on the model existing on the database. It would be nice to implement a solution which uses the model instance itself to avoid hitting the database and to use up-to-date field values not yet saved to the database. The patch I've included should fix these issues. An outline of the differences: - Using the descriptor protocol used in django.db.models.fields.subclassing. TimeZoneField uses the SubfieldBase metaclass. For LocalizedDateTimeField, instead of hooking into a signal I'm using a custom property descriptor and the `contribute_to_class` field method to provide the same functionality (doesn't need to use SubfieldBase in this case). This is related to issue 9. - The `timezone` keyword argument of the LocalizedDateTime field either accepts a string of a timezone name, a `datetime.tzinfo` subclass itself, or a callable which returns either of these types, but doesn't implicitly handle a query lookup. This implementation passes the model instance as the sole argument to the callable (if the callable expects it). So this provides a generic and more explicit entry point to do any variation of db lookup or just direct model instance attribute access:: class MyModel(models.Model): posted = LocalizedDateTimeField(timezone=lambda i: i.tz) tz = TimeZoneField() - The datetime localization happens on the LocalizedDateTimeField property getter instead of the setter. This is to ensure that the callable gets a fully initialized model instance passed to it. When a model instance is initialized from the db, or directly from python code via the constructor, not all field values might have been set on the model instance by the time a LocalizedDateTimeField is set. So for example, a corresponding TimeZoneField might not have been initialized until after the LocalizedDateTimeField is initialized. The localized datetime object is cached on the first property access, and the cached value is cleared when the property is set.
• Dec 20, 2008

  issue 8 (Purty Common Timezones in TimeZoneField) commented on by leah.culver   -   Woot.

  Woot.
• Dec 18, 2008

  issue 9 (TimeZoneField and LocalizedTimeZone should use the django.db...) reported by wejradford   -   According to the django docs, this will guarantee that .to_python() will always be called: * http://docs.djangoproject.com/en/dev/howto/custom-model-fields/#the-subfieldbase-metaclass AFAIK, at the moment, when you access a timezones.fields.TimeZoneField, you get the unicode timezone name rather than the TzInfo object. Thanks for the app, very useful!

  According to the django docs, this will guarantee that .to_python() will always be called: * http://docs.djangoproject.com/en/dev/howto/custom-model-fields/#the-subfieldbase-metaclass AFAIK, at the moment, when you access a timezones.fields.TimeZoneField, you get the unicode timezone name rather than the TzInfo object. Thanks for the app, very useful!
• Dec 11, 2008

  r41 (Fixed some breakage with some recent changes.) committed by brosner   -   Fixed some breakage with some recent changes.

  Fixed some breakage with some recent changes.
• Dec 11, 2008

  issue 5 (forms.LocalizedDateTimeField can't handle required=False) Status changed by brosner   -  

  Status: Accepted

  Status: Accepted
• Dec 11, 2008

  r40 (Tests for r38. Ensure required=False works on a TimeZoneFiel...) committed by brosner   -   Tests for r38. Ensure required=False works on a TimeZoneField.

  Tests for r38. Ensure required=False works on a TimeZoneField.
• Dec 11, 2008

  issue 6 (tests fail when not run from UTC?) Status changed by brosner   -   I have fixed this in r39. Thanks!

  Status: Fixed

  I have fixed this in r39. Thanks!

  Status: Fixed
• Dec 11, 2008

  r39 (Fixed issue #6 -- Ensure the decorator tests run when while ...) committed by brosner   -   Fixed issue #6 -- Ensure the decorator tests run when while TIME_ZONE is set to UTC. Thanks mandric for reporting this.

  Fixed issue #6 -- Ensure the decorator tests run when while TIME_ZONE is set to UTC. Thanks mandric for reporting this.
• Dec 11, 2008

  issue 7 (TimeZoneField's clean() raises exception when given an empty...) Status changed by brosner   -   I have committed your patch in r38. Thanks!

  Status: Fixed

  I have committed your patch in r38. Thanks!

  Status: Fixed
• Dec 11, 2008

  r38 (Fixed issue #7 -- Dont throw an exception when TimeZoneField...) committed by brosner   -   Fixed issue #7 -- Dont throw an exception when TimeZoneField.clean is given an empty value. Thanks robert.w.thomas for the patch.

  Fixed issue #7 -- Dont throw an exception when TimeZoneField.clean is given an empty value. Thanks robert.w.thomas for the patch.
• Dec 11, 2008

  issue 8 (Purty Common Timezones in TimeZoneField) Status changed by brosner   -   I have committed the code in r36 we discussed in #pinax. I am going to open a new ticket to support the preferred option I mentioned.

  Status: Fixed

  I have committed the code in r36 we discussed in #pinax. I am going to open a new ticket to support the preferred option I mentioned.

  Status: Fixed
• Dec 11, 2008

  r37 (Removed backward compatibility of imports.) committed by brosner   -   Removed backward compatibility of imports.

  Removed backward compatibility of imports.
• Dec 11, 2008

  r36 (Renamed TIMEZONE_CHOICES to ALL_TIMEZONE_CHOICES and added C...) committed by brosner   -   Renamed TIMEZONE_CHOICES to ALL_TIMEZONE_CHOICES and added COMMON_TIMEZONE_CHOICES and PRETTY_TIMEZONE_CHOICES (shows the GMT offset in the label). This commit preserves backward compatibility of imports which will be removed shortly. This changes the default choices for the TimeZoneField to PRETTY_TIMEZONE_CHOICES since this would seem to be the most common among users. Fixes issue #8 . Thanks Leah Culver for the idea.

  Renamed TIMEZONE_CHOICES to ALL_TIMEZONE_CHOICES and added COMMON_TIMEZONE_CHOICES and PRETTY_TIMEZONE_CHOICES (shows the GMT offset in the label). This commit preserves backward compatibility of imports which will be removed shortly. This changes the default choices for the TimeZoneField to PRETTY_TIMEZONE_CHOICES since this would seem to be the most common among users. Fixes issue #8 . Thanks Leah Culver for the idea.
• Dec 09, 2008

  issue 8 (Purty Common Timezones in TimeZoneField) Status changed by brosner   -   This would be useful. I have started working on this locally.

  Status: Started

  This would be useful. I have started working on this locally.

  Status: Started
• Dec 09, 2008

  issue 8 (Purty Common Timezones in TimeZoneField) reported by leah.culver   -   It would be nice to have a time zone picker with a shorter, cute list of options. See attached screenshot... only not US-centric.

  It would be nice to have a time zone picker with a shorter, cute list of options. See attached screenshot... only not US-centric.
• Nov 17, 2008

  issue 7 (TimeZoneField's clean() raises exception when given an empty...) reported by robert.w.thomas   -   ChoiceField will raise an exception if an invalid value is submitted, unless it is blank. It is possible to do this by using a different widget or by submitting the field using a library like urllib. TimeZoneField should be able to gracefully handle an empty value. What steps will reproduce the problem? 1. Submit an empty value to a TimeZoneField 2. pytz.timezone raises UnknownTimeZoneError What is the expected output? What do you see instead? clean() should return the blank or None value What version of the product are you using? On what operating system? rev 35, pytz2008i, Windows Please provide any additional information below. Fixing this is also useful if someone wanted to add an empty choice to make the field not required.

  ChoiceField will raise an exception if an invalid value is submitted, unless it is blank. It is possible to do this by using a different widget or by submitting the field using a library like urllib. TimeZoneField should be able to gracefully handle an empty value. What steps will reproduce the problem? 1. Submit an empty value to a TimeZoneField 2. pytz.timezone raises UnknownTimeZoneError What is the expected output? What do you see instead? clean() should return the blank or None value What version of the product are you using? On what operating system? rev 35, pytz2008i, Windows Please provide any additional information below. Fixing this is also useful if someone wanted to add an empty choice to make the field not required.
• Nov 17, 2008

  issue 5 (forms.LocalizedDateTimeField can't handle required=False) commented on by robert.w.thomas   -   This is an issue with anything that uses adjust_datetime_to_timezone that might be passing None, including the template filter (which should never raise an exception). Just allowing adjust_datetime_to_timezone to return None if it is passed None fixes all of this.

  This is an issue with anything that uses adjust_datetime_to_timezone that might be passing None, including the template filter (which should never raise an exception). Just allowing adjust_datetime_to_timezone to return None if it is passed None fixes all of this.
• Nov 15, 2008

  r35 (Force pytz 2008i.) committed by brosner   -   Force pytz 2008i.

  Force pytz 2008i.
• Nov 15, 2008

  r34 (Added the pytz dependancy to setup.py.) committed by brosner   -   Added the pytz dependancy to setup.py.

  Added the pytz dependancy to setup.py.
• Nov 15, 2008

  r33 (Added a setup.py file for easy_install and the like.) committed by brosner   -   Added a setup.py file for easy_install and the like.

  Added a setup.py file for easy_install and the like.
• Oct 22, 2008

  issue 6 (tests fail when not run from UTC?) commented on by mandric   -   This is with timezones svn rev 32 and django 1.0.X.

  This is with timezones svn rev 32 and django 1.0.X.
• Oct 22, 2008

  issue 6 (tests fail when not run from UTC?) reported by mandric   -   What steps will reproduce the problem? ./manage.py test What is the expected output? What do you see instead? I expected to see successful tests of course. What version of the product are you using? On what operating system? svn rev 1082 OSX, using macports python Please provide any additional information below. Is the test even designed to run successfully from a project that is including it? In the keystone project I have settings.TIME_ZONE = 'America/Chicago'. Here's the trace: .................F ====================================================================== FAIL: Doctest: timezones.tests.__test__.DECORATOR_TESTS ---------------------------------------------------------------------- Traceback (most recent call last): File "/opt/local/lib/python2.5/site-packages/django/test/_doctest.py", line 2180, in runTest raise self.failureException(self.format_failure(new.getvalue())) AssertionError: Failed doctest test for timezones.tests.__test__.DECORATOR_TESTS File "/Users/mandric/dev/keystone/timezones/tests.py", line unknown line number, in DECORATOR_TESTS ---------------------------------------------------------------------- File "/Users/mandric/dev/keystone/timezones/tests.py", line ?, in timezones.tests.__test__.DECORATOR_TESTS Failed example: foo.localdatetime Expected: datetime.datetime(2008, 6, 21, 9, 58, 17, tzinfo=<DstTzInfo 'Australia/Lindeman' EST+10:00:00 STD>) Got: datetime.datetime(2008, 6, 21, 14, 58, 17, tzinfo=<DstTzInfo 'Australia/Lindeman' EST+10:00:00 STD>) ---------------------------------------------------------------------- File "/Users/mandric/dev/keystone/timezones/tests.py", line ?, in timezones.tests.__test__.DECORATOR_TESTS Failed example: foo.datetime Expected: datetime.datetime(2008, 6, 12, 13, 50, tzinfo=<UTC>) Got: datetime.datetime(2008, 6, 12, 8, 50, tzinfo=<DstTzInfo 'America/Chicago' CDT-1 day, 19:00:00 DST>) ---------------------------------------------------------------------- Ran 18 tests in 13.763s FAILED (failures=1) Destroying test database...

  What steps will reproduce the problem? ./manage.py test What is the expected output? What do you see instead? I expected to see successful tests of course. What version of the product are you using? On what operating system? svn rev 1082 OSX, using macports python Please provide any additional information below. Is the test even designed to run successfully from a project that is including it? In the keystone project I have settings.TIME_ZONE = 'America/Chicago'. Here's the trace: .................F ====================================================================== FAIL: Doctest: timezones.tests.__test__.DECORATOR_TESTS ---------------------------------------------------------------------- Traceback (most recent call last): File "/opt/local/lib/python2.5/site-packages/django/test/_doctest.py", line 2180, in runTest raise self.failureException(self.format_failure(new.getvalue())) AssertionError: Failed doctest test for timezones.tests.__test__.DECORATOR_TESTS File "/Users/mandric/dev/keystone/timezones/tests.py", line unknown line number, in DECORATOR_TESTS ---------------------------------------------------------------------- File "/Users/mandric/dev/keystone/timezones/tests.py", line ?, in timezones.tests.__test__.DECORATOR_TESTS Failed example: foo.localdatetime Expected: datetime.datetime(2008, 6, 21, 9, 58, 17, tzinfo=<DstTzInfo 'Australia/Lindeman' EST+10:00:00 STD>) Got: datetime.datetime(2008, 6, 21, 14, 58, 17, tzinfo=<DstTzInfo 'Australia/Lindeman' EST+10:00:00 STD>) ---------------------------------------------------------------------- File "/Users/mandric/dev/keystone/timezones/tests.py", line ?, in timezones.tests.__test__.DECORATOR_TESTS Failed example: foo.datetime Expected: datetime.datetime(2008, 6, 12, 13, 50, tzinfo=<UTC>) Got: datetime.datetime(2008, 6, 12, 8, 50, tzinfo=<DstTzInfo 'America/Chicago' CDT-1 day, 19:00:00 DST>) ---------------------------------------------------------------------- Ran 18 tests in 13.763s FAILED (failures=1) Destroying test database...
• Oct 12, 2008

  issue 5 (forms.LocalizedDateTimeField can't handle required=False) reported by akaihola   -   What steps will reproduce the problem? 1. create a LocalizedDateTimeField(required=False) in a form 2. omit the value for that field when submitting the form 3. call is_valid() for the form What is the expected output? What do you see instead? is_valid() should return True, but it throws the following exception instead: Traceback (most recent call last): File "django/forms/forms.py", line 120, in is_valid return self.is_bound and not bool(self.errors) File "django/forms/forms.py", line 111, in _get_errors self.full_clean() File "django/forms/forms.py", line 231, in full_clean value = field.clean(value) File "pinax/apps/external_apps/timezones/forms.py", line 37, in clean return adjust_datetime_to_timezone(value, from_tz=self.timezone) File "pinax/apps/external_apps/timezones/utils.py", line 21, in adjust_datetime_to_timezone if value.tzinfo is None: AttributeError: 'NoneType' object has no attribute 'tzinfo' What version of the product are you using? On what operating system? Revision 32 on Ubuntu 8.04 with Python 2.5. Please provide any additional information below. Tests and patch attached.

  What steps will reproduce the problem? 1. create a LocalizedDateTimeField(required=False) in a form 2. omit the value for that field when submitting the form 3. call is_valid() for the form What is the expected output? What do you see instead? is_valid() should return True, but it throws the following exception instead: Traceback (most recent call last): File "django/forms/forms.py", line 120, in is_valid return self.is_bound and not bool(self.errors) File "django/forms/forms.py", line 111, in _get_errors self.full_clean() File "django/forms/forms.py", line 231, in full_clean value = field.clean(value) File "pinax/apps/external_apps/timezones/forms.py", line 37, in clean return adjust_datetime_to_timezone(value, from_tz=self.timezone) File "pinax/apps/external_apps/timezones/utils.py", line 21, in adjust_datetime_to_timezone if value.tzinfo is None: AttributeError: 'NoneType' object has no attribute 'tzinfo' What version of the product are you using? On what operating system? Revision 32 on Ubuntu 8.04 with Python 2.5. Please provide any additional information below. Tests and patch attached.
• Sep 18, 2008

  r32 (Fixed a reference to the old .rst in the toctree of index.tx...) committed by brosner   -   Fixed a reference to the old .rst in the toctree of index.txt.

  Fixed a reference to the old .rst in the toctree of index.txt.
• Sep 18, 2008

  r31 (Moved documentation to .txt extension to comply with Pinax a...) committed by brosner   -   Moved documentation to .txt extension to comply with Pinax and Django. Mostly Django.

  Moved documentation to .txt extension to comply with Pinax and Django. Mostly Django.
• Sep 10, 2008

  r30 (Made the source code consistent with correct conventions fol...) committed by brosner   -   Made the source code consistent with correct conventions following Django specifications.

  Made the source code consistent with correct conventions following Django specifications.
• Aug 22, 2008

  r29 (Added how_to_use.rst to a toctree for Sphinx to quit complai...) committed by brosner   -   Added how_to_use.rst to a toctree for Sphinx to quit complaining.

  Added how_to_use.rst to a toctree for Sphinx to quit complaining.
• Aug 22, 2008

  r28 (Added the roots of more documentation.) committed by brosner   -   Added the roots of more documentation.

  Added the roots of more documentation.
• Aug 07, 2008

  issue 4 (Error on save datetime in MySQL) reported by tranceway   -   This line: http://code.google.com/p/django-timezones/source/browse/trunk/timezones/utils.py#25 returns a datetime object with the correspondent timezone, but when i try to save the form... django converte de datetime to str with this format: AAAA-MM-DD HH:MM:SS+HH:MM this format is not mysql datetime field compatible my nusty solution for the moment is change the adjust_datetime_to_timezone to return a valid string :(

  This line: http://code.google.com/p/django-timezones/source/browse/trunk/timezones/utils.py#25 returns a datetime object with the correspondent timezone, but when i try to save the form... django converte de datetime to str with this format: AAAA-MM-DD HH:MM:SS+HH:MM this format is not mysql datetime field compatible my nusty solution for the moment is change the adjust_datetime_to_timezone to return a valid string :(
• Aug 07, 2008

  r27 (proper fix for new singlas framework ) committed by doug.napoleone   -   proper fix for new singlas framework

  proper fix for new singlas framework
• Aug 07, 2008

  r26 (update for new django signals changes ) committed by doug.napoleone   -   update for new django signals changes

  update for new django signals changes
• Aug 05, 2008

  r25 (Not really sure why there was a problem. ) committed by doug.napoleone   -   Not really sure why there was a problem.

  Not really sure why there was a problem.