[Testbot] Plone 4.3 - Python 2.7 - Build # 2080 - Still failing! - 1 failure(s)
jenkins at plone.org
jenkins at plone.org
Sat Mar 22 07:18:37 UTC 2014
-------------------------------------------------------------------------------
Plone 4.3 - Python 2.7 - Build # 2080 - Still Failing!
-------------------------------------------------------------------------------
http://jenkins.plone.org/job/plone-4.3-python-2.7/2080/
-------------------------------------------------------------------------------
CHANGES
-------------------------------------------------------------------------------
Repository: plone.app.form
Branch: refs/heads/2.2.x
Date: 2014-03-22T07:33:15+01:00
Author: tisto (tisto) <tisto at plone.org>
Commit: https://github.com/plone/plone.app.form/commit/29aa5df17ed4184fa92869b9e20145fa7efe8f8a
Fix failing datecomponents test. I don't have the slightest idea what difference it makes if the returned value is one hour off (20 instead of 21). On my local machine (different time zone) I get (2499, '12', '30', '15', '00').
Files changed:
M plone/app/form/widgets/datecomponents.txt
diff --git a/plone/app/form/widgets/datecomponents.txt b/plone/app/form/widgets/datecomponents.txt
index 601cf98..ba6c588 100644
--- a/plone/app/form/widgets/datecomponents.txt
+++ b/plone/app/form/widgets/datecomponents.txt
@@ -1,25 +1,25 @@
CalendarWidget
===================
-There are no tests for this at all and I want to make a change. This is
+There are no tests for this at all and I want to make a change. This is
a scary adventure!
>>> from plone.app.form.widgets import datecomponents
>>> from zope.publisher.browser import TestRequest
>>> request = TestRequest()
>>> view = datecomponents.DateComponents(self.portal, request)
-
-For historical reasons, the DateTime module parses the timezone differently
-if a date is created with a "-" instead of a "/". Dates
-that enter here with a "-" go to "GMT-0" by default whereas "/" goes to
+
+For historical reasons, the DateTime module parses the timezone differently
+if a date is created with a "-" instead of a "/". Dates
+that enter here with a "-" go to "GMT-0" by default whereas "/" goes to
the server timezone (in my case this is "US/Pacific"). The bug:
-Note that this explanation won't work on certain timezones and
-DateTime doesn't look at anything obvious to get the timezone
-info (like environment variables) so I'm going to patch the func
-that sets the timezone so that this explanation test doesn't
-break on different timezones. If this test does break then, it
-means that the actual bug has been fixed. There maybe other signs
+Note that this explanation won't work on certain timezones and
+DateTime doesn't look at anything obvious to get the timezone
+info (like environment variables) so I'm going to patch the func
+that sets the timezone so that this explanation test doesn't
+break on different timezones. If this test does break then, it
+means that the actual bug has been fixed. There maybe other signs
such as pigs flying, locusts, etc...
>>> import DateTime
@@ -28,8 +28,8 @@ such as pigs flying, locusts, etc...
>>> def fakeLocalZone(self, ltm=None):
... return TEST_TIME_ZONE
>>> DateTime.DateTime.localZone = fakeLocalZone
-
-
+
+
>>> him = DateTime.DateTime("2011/01/13")
>>> her = DateTime.DateTime("2011-01-13")
>>> her == him
@@ -45,16 +45,16 @@ to the localzone:
'12'
>>> him.strftime('%d')
'13'
-
-For the next test case, we want them to work in all timezones so
+
+For the next test case, we want them to work in all timezones so
we un-monkey patch.
>>> DateTime.DateTime.localZone = realLocalZone
-It would be sane to fix it in the DateTime module, but I wouldn't wish
-that task upon my worst enemy. So we can fix it here by replacing all
+It would be sane to fix it in the DateTime module, but I wouldn't wish
+that task upon my worst enemy. So we can fix it here by replacing all
instances of "-" with "/" in the first part of a date string:
-
+
>>> date = "2011-01-13"
>>> parts = view.result(date=date)
>>> parts['days'][13]['selected']
@@ -63,8 +63,8 @@ instances of "-" with "/" in the first part of a date string:
>>> parts = view.result(date=date)
>>> parts['days'][13]['selected']
1
-
-Helper function to parse through the next return values without losing
+
+Helper function to parse through the next return values without losing
whatever sanity is left
>>> def parseDate(parts):
... date = ()
@@ -74,12 +74,12 @@ whatever sanity is left
... if item['selected'] == 1:
... date += (item['value'],)
... return date
-
-Additionally, there was a note that DateTime didn't support GMT and then
-was stripping it off. I don't think that is still the case and it
+
+Additionally, there was a note that DateTime didn't support GMT and then
+was stripping it off. I don't think that is still the case and it
causes whacky jackiness for people who actually want to pass in time zones.
-For example, we can pass in GMT-5 here and it should (correctly?) remap
-US/Eastern to the localzone (which we will again patch to make sure this
+For example, we can pass in GMT-5 here and it should (correctly?) remap
+US/Eastern to the localzone (which we will again patch to make sure this
test case doesn't fail):
>>> DateTime.DateTime.localZone = fakeLocalZone
@@ -87,45 +87,45 @@ test case doesn't fail):
>>> parts = view.result(date=date)
>>> parseDate(parts)
(2011, '01', '12', '22', '30')
-
-And to be sure, we also can't break other tz representations. I won't test
+
+And to be sure, we also can't break other tz representations. I won't test
for time here because it will break half of every year do to daylight savings.
>>> date = "2011/01/13 01:30 US/Pacific"
>>> parts = view.result(date=date)
>>> parseDate(parts)
(2011, '01', '13', '01', '30')
-
-While we are in here, let's fix this edge case as well. The date should
-always round up to the next interval. There is the edge case of times that
+
+While we are in here, let's fix this edge case as well. The date should
+always round up to the next interval. There is the edge case of times that
are greater than the the last interval. Instead of messing with logic about
-rounding to the next hour then the next day, etc, etc... let's just round down
+rounding to the next hour then the next day, etc, etc... let's just round down
to the last interval
>>> date = "2011/01/13 05:59 US/Pacific"
>>> parts = view.result(date=date)
>>> parseDate(parts)
(2011, '01', '13', '05', '55')
-
+
And some backwards compatibility checks
>>> date = "2011/01/13 05:55 US/Pacific"
>>> parts = view.result(date=date)
>>> parseDate(parts)
(2011, '01', '13', '05', '55')
-
+
>>> parts = view.result(date="2011/01/13 05:47 US/Pacific")
>>> parseDate(parts)
(2011, '01', '13', '05', '50')
-
+
>>> parts = view.result(date="2011/01/13 05:51 US/Pacific")
>>> parseDate(parts)
(2011, '01', '13', '05', '55')
-
+
>>> parts = view.result(date="2011/01/13 06:00 US/Pacific")
>>> parseDate(parts)
(2011, '01', '13', '06', '00')
-
+
Pre-epoch dates need to work too
>>> parts = view.result(date="1961/01/13 06:00 US/Pacific")
@@ -151,7 +151,7 @@ Test date after 2500
>>> date = "2501-01-30 22:00 US/Pacific"
>>> parts = view.result(date=date)
>>> parseDate(parts)
- (2499, '12', '30', '21', '00')
+ (2499, '12', '30', '20', '00')
un-monkey patch
>>> DateTime.DateTime.localZone = realLocalZone
-------------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CHANGES.log
Type: application/octet-stream
Size: 7027 bytes
Desc: not available
URL: <http://lists.plone.org/pipermail/plone-testbot/attachments/20140322/c9f84e8b/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build.log
Type: application/octet-stream
Size: 81575 bytes
Desc: not available
URL: <http://lists.plone.org/pipermail/plone-testbot/attachments/20140322/c9f84e8b/attachment-0003.obj>
More information about the Testbot
mailing list