Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Big bad DateTime bug workaround for correct ulocalized_time() timezone support #47

Merged
merged 3 commits into from

2 participants

Sean Upton Johannes Raggam
Sean Upton
Collaborator

See http://plone.293351.n2.nabble.com/ulocalized-time-fails-for-non-system-local-timezone-lt-big-DateTime-fail-tt7558133.html for discussion of bug.

We have to work around it to display the times correct for the timezone displayed in event_view. Any use of ulocaliized_time() in an add-on to Plone where dates involved have timezones should be suspect. This solution wraps the call, and replaces the instance with an instance of a fixed DateTime subclass that does strftime without bug.

seanupton added some commits
Sean Upton seanupton commented out pdb.set_trace() in tests cbe6a86
Sean Upton seanupton work around bug in DateTime.strftime that always normalizes displayed…
… date to the system timezone, regardless of the timezone on the DateTime value itself. This bug is not likely to get fixed in Zope DateTime upstream soon (long-standing), so Products.CMFPlone.i18nl10n.ulocalized_time is subject to triggering it -- here that function is wrapped with a local copy that does the right thing with the timezone by using datetime.datetime.strftime without broken magic of DateTime.strftime.
994224f
Johannes Raggam
Owner

without trying to understand the whole issue in detail (have my head in another tricky problem ATM), i shoot out some naive questions:

  • do you think, the solution can be better done in zope's DateTime? then the fix should go there, probably

  • this affects mostly the AT types of plone.app.event, or? (just asking to understand you have worked with the ATEvent type of plone.app.event too)

  • regarding the DT2dt function, did you see the plone.event.utils.pydt function? if it can be used with your patch, we should use this one

Sean Upton
Collaborator

Yes, DT2dt() is (in practical terms) duplicative of pydt(). Both preserve the timezone and DST correctly, which was my goal, so I will remove DT2dt and use pydt().

Sean Upton seanupton remove duplicative transformation function DT2dt, use plone.event.uti…
…ls.pydt() instead, as both behave similarly with respect to timezone and DST in conversion.
44544a9
Sean Upton
Collaborator

Since this affects any date display in plone.app.event where the date is not in the system timezone, it seems reasonable to try and fix this here now (with the value-wrapping) and then push this to both Plone (Products.CMFPlone.i18nl10n) and Zope (DateTime in zope svn) upstreams -- in that order.

Johannes Raggam thet merged commit 44544a9 into from
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Aug 22, 2012
  1. Sean Upton
  2. Sean Upton

    work around bug in DateTime.strftime that always normalizes displayed…

    seanupton authored
    … date to the system timezone, regardless of the timezone on the DateTime value itself. This bug is not likely to get fixed in Zope DateTime upstream soon (long-standing), so Products.CMFPlone.i18nl10n.ulocalized_time is subject to triggering it -- here that function is wrapped with a local copy that does the right thing with the timezone by using datetime.datetime.strftime without broken magic of DateTime.strftime.
  3. Sean Upton

    remove duplicative transformation function DT2dt, use plone.event.uti…

    seanupton authored
    …ls.pydt() instead, as both behave similarly with respect to timezone and DST in conversion.
This page is out of date. Refresh to see the latest.
21 plone/app/event/base.py
View
@@ -1,6 +1,8 @@
import pytz
from DateTime import DateTime
from Products.CMFCore.utils import getToolByName
+from Products.CMFPlone import i18nl10n
+from Products.CMFPlone.i18nl10n import ulocalized_time as orig_ulocalized_time
from datetime import date
from datetime import datetime
from datetime import timedelta
@@ -192,10 +194,10 @@ def DT(dt):
@param dt: python datetime instance
"""
-
tz = default_timezone(getSite())
if isinstance(dt, datetime):
- tz = validated_timezone(dt.tzname(), tz)
+ zone_id = getattr(dt.tzinfo, 'zone', tz)
+ tz = validated_timezone(zone_id, tz)
return DateTime(dt.year, dt.month, dt.day,\
dt.hour, dt.minute, dt.second, tz)
elif isinstance(dt, date):
@@ -248,3 +250,18 @@ def guess_date_from(datestr, context=None):
return
return pytz.timezone(default_timezone(context)).localize(dateobj)
+
+
+_strftime = lambda v, fmt: pydt(v).strftime(fmt)
+
+
+class PatchedDateTime(DateTime):
+
+ def strftime(self, fmt):
+ return _strftime(self, fmt)
+
+
+def ulocalized_time(time, *args, **kwargs):
+ """Corrects for DateTime bugs doing wrong thing with timezones"""
+ wrapped_time = PatchedDateTime(time)
+ return orig_ulocalized_time(wrapped_time, *args, **kwargs)
3  plone/app/event/browser/event_view.py
View
@@ -1,9 +1,8 @@
-from Products.CMFPlone.i18nl10n import ulocalized_time
from Products.Five.browser import BrowserView
from plone.event.interfaces import IEventAccessor, IRecurrenceSupport
from plone.event.utils import is_same_day, is_same_time
-from plone.app.event.base import DT
+from plone.app.event.base import DT, ulocalized_time
def prepare_for_display(context, start, end, whole_day):
2  plone/app/event/tests/test_atevent_integration.py
View
@@ -24,7 +24,7 @@ def test_event_accessor(self):
e1 = self.portal['event1']
# setting attributes via the accessor
- import pdb; pdb.set_trace()
+ #import pdb; pdb.set_trace()
acc = IEventAccessor(e1)
acc.end = datetime(2011,11,13,10,0)
acc.timezone = 'CET'
Something went wrong with that request. Please try again.