RDFLib/rdflib — Issue #175: Test failures with new clone of repository
Author: gjhiggins
Created: 2012-02-20 08:34:26+00:00
State: open

gklyn...@gmail.com, 2011-09-12T09:43:28.000Z

(Apologies if this is a known issue or problem at my end. I followed the instructions at http://code.google.com/p/rdflib/wiki/DeveloperGuide.)

What steps will reproduce the problem?
1. clone repository to local machine
2. sudo easy_install nose
3. python run_tests.py

What is the expected output? What do you see instead?
Expecting no errors. Seeing a small number of errors and failures:

Ran 297 tests in 102.703s
FAILED (errors=4, failures=1)

Copy of full test run output in attached file.

What version of the product are you using? On what operating system?

MacOS 10.5 (Leopard), Python 2.7

[[
Python 2.7 (r27:82500, Aug 19 2010, 15:20:44)
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
dlopen("/sw/lib/python2.7/lib-dynload/readline.so", 2);
import readline # dynamically loaded from /sw/lib/python2.7/lib-dynload/readline.so
]]

[[
tinos:googlecode_rdflib graham$ hg summary
parent: 1481:f0d513e4edb0 tip
encoding keyword missing for rdfa parser
branch: default
commit: (clean)
update: 1 new changesets, 2 branch heads (merge)
]]

Please provide any additional information below.

Comment 1 by gjhigg...@gmail.com
Those are indeed real test failures and not something at your end. See also http://bel-epa.com/hudson/job/rdflib/22/testReport/.

A fix for the parse_date_time doctest failure has proved elusive, mainly because the failure has proved impossible to reproduce outside the UK.

HTH

Comment 2 by gjhigg...@gmail.com
Now fixed, see http://bel-epa.com/hudson/job/rdflib/

Comment 3 by gklyn...@gmail.com
Most bugs are fixed. I still get the parse_date_time error ... I'll see if I can track it down.

Comment 4 by gklyn...@gmail.com
I managed to fix the date_time doctest in my working copy. It seems to be daylight savings time related (maybe timezone related?) so I can't be sure if it works in all timezones as intended.

Refs:
http://docs.python.org/library/time.html#time.mktime (and table of conversion functions on same page)
http://docs.python.org/library/calendar.html#calendar.timegm

A patch (which does not delete any original code, but overwrites the result, is:
[[
# HG changeset patch
# User Graham Klyne
# Date 1316634766 -3600
# Node ID 98a2ae400c4bbcc8475339906450b0691c1e98f4
# Parent 0432070a728a216cf6c76d0c11e231397d4b4fd7
Use calendar.timegm instead of time.mktime to avoid DST problem

diff -r 0432070a728a -r 98a2ae400c4b rdflib/util.py
--- a/rdflib/util.py	Tue Sep 20 18:15:54 2011 +0100
+++ b/rdflib/util.py	Wed Sep 21 20:52:46 2011 +0100
@@ -60,6 +60,7 @@

from time import mktime, time, gmtime, localtime, timezone, altzone, daylight
+from calendar import timegm

def date_time(t=None, local_time_zone=False):
"""http://www.w3.org/TR/NOTE-datetime ex: 1997-07-16T19:20:30Z
@@ -135,6 +136,10 @@
t = mktime((int(year), int(month), int(day), int(hour),
int(minute), int(second), 0, 0, 0))
t = t - timezone + tz_offset
+ # Alternative handles case when local time is DST
+ t = timegm((int(year), int(month), int(day), int(hour),
+ int(minute), int(second), 0, 0, 0))
+ t = t + tz_offset
return t

def from_n3(s, default=None, backend=None):
]]