Greetings ~ I have been experiencing a "TimeError" in Zope 2.8.5 instance running on Python 2.3.5. -- Site Error An error was encountered while publishing this resource. Error Type: TimeError Error Value: The time 106900545747.045975 is beyond the range of this Python implementation. -- Here's the traceback... -- TimeError Sorry, a site error occurred. Traceback (innermost last): * Module ZPublisher.Publish, line 113, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 40, in call_object * Module Shared.DC.Scripts.Bindings, line 311, in __call__ * Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec * Module App.special_dtml, line 175, in _exec * Module DocumentTemplate.DT_Var, line 214, in render * Module App.PersistentExtra, line 34, in bobobase_modification_time * Module DateTime.DateTime, line 509, in __init__ * Module DateTime.DateTime, line 760, in _parse_args * Module DateTime.DateTime, line 437, in safelocaltime TimeError: The time 106900545747.045975 is beyond the range of this Python implementation. -- The error is mostly noticed in the ZMI. I can't view a large percentage of pages in the Content frame of the ZMI, including the Root Folder view. It has been a hugely problematic issue for me. This error began when my hosting account was moved from Zettai.net to HighSpeedRails.com. I did not have the error on Zettai. I didn't change anything after my data was moved to HSR that would have caused the error. In trying to solve the issue with HSR, I have been told that the error is coming from my data. I have rather thoroughly checked my data for the time value and have not come up with anything. I spoke to someone who thought, since the error is pervasive and the traceback points to the basic rendering of the object and a system property, I might have no control over it. The TimeError might indicate something with the setup of the hosting environment. - The "time" value is always the same. - I have been told 106900545747.045975 converts to: Tue May 22 1973 01:35:45 GMT-0500. I have learned that DateTime sometimes has issues with dates outside of 1970 - 2038. 1973 should fall within the acceptable range. - When I asked HSR if there was any difference in the way that time is being handled on the new servers that is different from the old servers, I found that my old account was on CST and the new account is on EST. Not sure if that matters or not. - I found the following links pertaining to the TimeError: http://marc.theaimsgroup.com/?l=zope-db&m=109044731701981&w=2 http://mail.zope.org/pipermail/zope-checkins/2003-November/025122.html - I did trace the error back to "safelocaltime" in DateTime.py If anyone knows anything about the TimeError and could pass a few clues my way I would really appreciate it. I'd like to find out how/why the hosting environment handles the dates differently. Thank you very much ~ John McIntyre 612 423 9692 john@johnnyflash.com
On Mon, Nov 20, 2006 at 05:48:24PM -0600, John McIntyre wrote:
- I have been told 106900545747.045975 converts to: Tue May 22 1973 01:35:45 GMT-0500. I have learned that DateTime sometimes has issues with dates outside of 1970 - 2038. 1973 should fall within the acceptable range.
Heh, nope. ./bin/zopectl debug ...
print DateTime.DateTime(106900545747.045975).ISO() 5357-07-17 15:02:27
-- Paul Winkler http://www.slinkp.com
Paul Winkler wrote at 2006-11-20 22:00 -0500:
On Mon, Nov 20, 2006 at 05:48:24PM -0600, John McIntyre wrote:
- I have been told 106900545747.045975 converts to: Tue May 22 1973 01:35:45 GMT-0500. I have learned that DateTime sometimes has issues with dates outside of 1970 - 2038. 1973 should fall within the acceptable range.
Heh, nope.
./bin/zopectl debug ...
print DateTime.DateTime(106900545747.045975).ISO() 5357-07-17 15:02:27
Looks you have a newer "DateTime" implementation. The posted traceback clearly shows the the posters "DateTime" implementation clearly has had problems... -- Dieter
On Tue, Nov 21, 2006 at 09:02:52PM +0100, Dieter Maurer wrote:
Paul Winkler wrote at 2006-11-20 22:00 -0500:
On Mon, Nov 20, 2006 at 05:48:24PM -0600, John McIntyre wrote:
- I have been told 106900545747.045975 converts to: Tue May 22 1973 01:35:45 GMT-0500. I have learned that DateTime sometimes has issues with dates outside of 1970 - 2038. 1973 should fall within the acceptable range.
Heh, nope.
./bin/zopectl debug ...
print DateTime.DateTime(106900545747.045975).ISO() 5357-07-17 15:02:27
Looks you have a newer "DateTime" implementation.
The posted traceback clearly shows the the posters "DateTime" implementation clearly has had problems...
Yeah, I don't know what's up with that. Mainly I just wanted to correct one piece of misinformation, "- I have been told 106900545747.045975 converts to: Tue May 22 1973 01:35:45" That's wrong by several millenia, and the Python standard library agrees with (zope 2.9.1) DateTime.DateTime on this:
import time time.localtime(106900545747.045975).tm_year 5357
-- Paul Winkler http://www.slinkp.com
Paul Winkler wrote at 2006-11-21 16:27 -0500:
... "- I have been told 106900545747.045975 converts to: Tue May 22 1973 01:35:45" That's wrong by several millenia, and the Python standard library agrees with (zope 2.9.1) DateTime.DateTime on this:
import time time.localtime(106900545747.045975).tm_year 5357
Now, we understand: it's the Python "time" implementation that has changed. With Python 2.3.3 (under Debian Sarge), we get:
from time import localtime localtime(106900545747.045975) (1901, 12, 13, 21, 45, 52, 4, 347, 0) localtime(106900545747.045975).tm_year 1901
-- Dieter
import time time.localtime(106900545747.045975).tm_year 5357
Now, we understand: it's the Python "time" implementation that has changed.
With Python 2.3.3 (under Debian Sarge), we get:
from time import localtime localtime(106900545747.045975) (1901, 12, 13, 21, 45, 52, 4, 347, 0) localtime(106900545747.045975).tm_year 1901
In my python 2.4.3 (compiled from source) and the one installed with the OS, which is also 2.4.3, it doesn't work. I get: Traceback (most recent call last): File "<stdin>", line 1, in ? ValueError: timestamp out of range for platform time_t So, I guess there should be something that you can configurate when building python, or it is perhaps a linux kernel paramater. With python 2.3.5 it works however, so, it is a change in python as Dieter mentioned. By running the zopectl in debug mode for zope 2.9.4, the resulting traceback is the same as the one posted by the OP. With zope 2.8.8 it runs without any problem. So, it could be that the provider is running zope 2.8.5 with python 2.4. Regards Josef
Josef Meile wrote at 2006-11-22 22:44 +0100:
import time time.localtime(106900545747.045975).tm_year 5357
Now, we understand: it's the Python "time" implementation that has changed.
With Python 2.3.3 (under Debian Sarge), we get:
from time import localtime localtime(106900545747.045975) (1901, 12, 13, 21, 45, 52, 4, 347, 0) localtime(106900545747.045975).tm_year 1901
In my python 2.4.3 (compiled from source) and the one installed with the OS, which is also 2.4.3, it doesn't work. I get:
Traceback (most recent call last): File "<stdin>", line 1, in ? ValueError: timestamp out of range for platform time_t
Another possibility is that the difference may come from the C runtime library. We now have several behaviours: the correct one, giving an unsane year (probably cause by some form of truncation) and raising an exception. It seems not to be Python nor DateTime.... -- Dieter
John McIntyre wrote at 2006-11-20 17:48 -0600:
... An error was encountered while publishing this resource.
Error Type: TimeError Error Value: The time 106900545747.045975 is beyond the range of this Python implementation.
You are lucky!
TimeError Sorry, a site error occurred. Traceback (innermost last): * Module ZPublisher.Publish, line 113, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 40, in call_object * Module Shared.DC.Scripts.Bindings, line 311, in __call__ * Module Shared.DC.Scripts.Bindings, line 348, in _bindAndExec * Module App.special_dtml, line 175, in _exec * Module DocumentTemplate.DT_Var, line 214, in render * Module App.PersistentExtra, line 34, in bobobase_modification_time * Module DateTime.DateTime, line 509, in __init__ * Module DateTime.DateTime, line 760, in _parse_args * Module DateTime.DateTime, line 437, in safelocaltime
TimeError: The time 106900545747.045975 is beyond the range of this Python implementation.
Looks like a corrupted storage.... The "bobobase_modification_time" should not be beyond 2036 (in fact, it should not be beyond "now"). Be happy, that you see this with such a (relatively) clear exception... -- Dieter
participants (4)
-
Dieter Maurer -
John McIntyre -
Josef Meile -
Paul Winkler