UnknownTimeZone when assigning Datetime field

Development Developing for Plone
, ,
1

I have registered a behavior which adds a field to my content.

contentmodified = schema.Datetime(
        title=_(u'label_contentmodified_date', u'Content Date'),
        description=_(
            u'help_contentmodified_date',
            default=u'This represents the date that the actual content was modified.'
                    u'Actual content is distinguished by being an update on the default fieldset.'),
        required=False
    )

It gets assigned like so:

class ContentModification(MetadataBase):
    def _get_content_last_modified(self):
        return self.context.contentmodified

    def _set_content_last_modified(self, value):
        self.context.contentmodified = value

    contentmodified = property(_get_content_last_modified, _set_content_last_modified)

When I go to assigned it after adapting,

           modification_adapter = IContentModification(content, None)

           if modification_adapter is not None:
               modification_adapter.contentmodified = old_date.asdatetime()

where old_date is a Zope 2 DateTime object, I get the following error:

UnknownTimeZoneError: (UnknownTimeZoneError('GMT-4',), <function _p at 0x23a2e60>, ('GMT-4',))

I have done some searching on the error and found that there is some issue in the pytz package where it may not produce the right outcome when the timezone is formatted as 'GMT-4' rather than 'Etc/GMT-4', but I updated the date directly and still get this error.

I am populating it from an object which I printed out and know is correct:
DateTime('2016/09/28 11:01:6.178786 Etc/GMT-4')

Does anyone know what could be the issue?

2

I think those time zones are no longer included in the pytz package... see Time zones in old DateTime objects

But why are you not using the "modified" date time that comes with Dublin core metadata?

3

Hey tkim. I saw your post @UnknownTimezoneError / pytz quirks, and it helped tremendously.

I am not able to use modified because that gets timestamped even when a non-substantive field such as table_of_contents gets changed. I wanted to originally write the add-on to only check when items are changed in the default fieldset, but that got a little too unpredictable. So I opted to only track edits by members of certain groups so that if an administrator updates a link, it doesn't show that as the last modified. Currency of our information is important. Therefore knowing the date the page was actually reviewed by a SME as opposed to an administrator is important.

1 Like
4

Glad I could help a bit. But are you still getting the error? What is the difference between the value that causes the error and (say) a DateTime value that doesn't?

5

I am actually no longer getting an error because I used your tzinfo.py hack which for these purposes of pulling in old-style dates is precise enough for us. For merging the old dates in, we would probably even be fine to capture the week of the old edits.

1 Like
6

The problem I'm still facing is that every time I view one of the migrated content items, the tzinfo.py hack still has to fix the missing time zones. I still want to try to go back and fix the pickles!

7

I was fortunately doing a less involved migration. I was able to get around needing the hack because I had printed out an object from a Plone 4.3 environment that looked like this:

{'<path>': DateTime(...),
 '<path>': DateTime(...),
 ...
}

All of my dates were GMT-4, so in the printed object from the legacy, I updated GMT-4 with Etc/GMT+4. Once I updated them all directly, I was able to Re-index and remove the hack.

It sounds like that might be a little involved for your needs since you migrated many date fields and did it through a pipeline if memory serves.

1 Like