I'm updating an old Plone 2.5 (yes!) add-on and migrating the old data to a Plone 5.0 site. I've run into time zones that cause an error when I try to view a migrated object.
Since Plone 2.5, the time zones database has changed: the time zones 'GMT-5' and 'GMT-6' have since been renamed 'Etc/GMT-5' and 'Etc/GMT-6'. Some DateTime values in legacy data use the old time zone designations, which causes an error in the unpickler() method in the file tzinfo.py, part of the pytz-2015.7-py2.7.egg. This error prevents viewing of legacy (migrated) OIEStudentApplication objects.
For the moment, the only way I've found to get around this error is to patch the unpickler() method in tzinfo.py and add the following lines right after line 525 (the comment "Raises a KeyError if zone no longer exists, which should never happen and would be a bug."):
# Raises a KeyError if zone no longer exists, which should never happen
# and would be a bug.
if zone == 'GMT-5':
logger.warn('fixing nonexistent timezone %s' % zone)
zone = 'Etc/GMT-5'
elif zone == 'GMT-6':
logger.warn('fixing nonexistent timezone %s' % zone)
zone = 'Etc/GMT-6'
tz = pytz.timezone(zone)
I've tried to step through the code at that spot but going up the stack I don't see how to get to the DateTime value so I can change it permanently (I see only the current object being unpickled; the current object contains the value, clearly)
Has anyone run into this problem before, and how could I find the values and fix them so I don't have to manually patch tzinfo.py?
I suspect it's the DateTime values for creation and modification obtained via created() and modified(): '2011-09-21T22:49:05-05:00', '2012-02-03T12:14:39-06:00'
You likely will not be able to find the (problematic DateTime) values from the context in which the exception is raised. The value is currently being constructed and the construction fails.
DateTime itself is not persistent; thus, the value is constructed as part of the loading of the enclosing persistent object (likely a content object). You should be able to determine its "_p_oid" from the above context.
In order to fix the problem, you must either have your patch activated or work before the migration. I would try the second approach: search all content objects and check their DateTime time zones and fix them, if necessary.
Thanks all for your help! I am going to try this out first and will report back, because 4.1.1 has what seems to be the exact fix I need.
Changelog
4.2 (2017-04-26)
Add support for Python 3.6, drop support for Python 3.3.
4.1.1 (2016-04-30)
Support unpickling instances having a numeric timezone like +0430.
4.1 (2016-04-03)
Add support for Python 3.4 and 3.5.
Drop support for Python 2.6 and 3.2.
4.0.1 (2013-10-15)
Provide more backward compatible timezones. [vangheem]
Oh duh I had posted earlier (but focused on the pytz package): UnknownTimezoneError / pytz quirks so in fact my patch code is incorrect (should replace GMT- with Etc/GMT+ and GMT+ with Etc/GMT-)
I am curious why we don't have the latest pytz (pytz-2017.2-py2.7.egg) in Plone 5.1b4 (which pins pytz-2016.10-py2.7.egg)
@tkimnguyen Have you learned anything additional about this since your last post here?
I am having an issue with Plone 4.3.10 and pytz throwing this error. Your original post mentioned "DateTime values in legacy data use the old time zone designations" but it seems that Plone 4.3.10 is writing timestamps in various places using those same "GMT-4" timezones. I am getting the error on some newly created custom objects, but as far as I can tell it is not on custom fields, just standard Plone attributes like created, modified, etc.
I have tried pinning DateTime to 4.2 but this did not help.
