RDFLib/rdflib — Issue #156: Implement date & time literals via isodate
Author: gjhiggins
Created: 2012-02-20 08:34:01+00:00
State: open

christop...@gmail.com, 2011-04-22T15:02:49.000Z

Here is a patch to substitute rdflib's own iso 8601 date, time & datetime parsing methods with methods from the isodate package.

Test cases are extended to further test datetime objects.

This adds an external dependeny to isodate package and needs to be communicated in setup.py and elsewhere.

Comment 1 by gromgull
Thanks!

I see no problem adding another dependency. If noone says anything by tomorrow I'll commit it!

Comment 2 by gromgull

Comment 3 by lindstr...@gmail.com
Would it be feasible to do a try-import and fallback on the stdlib (perhaps with a warning issued using the warnings module)? It's nice to only optionally depend on external things if possible.

Comment 4 by christop...@gmail.com
You can of course keep the old code as fallback but I'm not sure if it's worth the hassle. If you want to support different triple store backends you have to cope with various formattings and rdflib was pretty bad at it in the past.

Comment 5 by christop...@gmail.com
The way rdflib's setup.py is written triggers the following error when building a source package with the patch applied above:

$ python setup.py sdist
Traceback (most recent call last):
File "setup.py", line 6, in
from rdflib import __version__
File "/tmp/rdflib/rdflib/__init__.py", line 64, in
from rdflib.term import URIRef, BNode, Literal, Variable
File "/tmp/rdflib/rdflib/term.py", line 33, in
from isodate import parse_time, parse_date, parse_datetime
ImportError: No module named isodate

We had the same issue with SuRF and solved it the following way:
- Put the __version__ variable into rdflib/__version__.py
- Call "execfile('rdflib/__version__.py')" in setup.py
- and "from __version__ import *" in _rdflib/__init__.py

Comment 6 by danielmr...@gmail.com
I think rdflib should focus on handling rdf data. this does not include date parsing. isodate does that, so I don't think try-import and and fallback is a good idea. --> +1 for merging

Comment 7 by christop...@gmail.com
It seems properly supporting timezones can pose a compatibility issue:

With this patch included all date, time & datetime objects will properly return timezone information. However Python cannot compare timezone-less values to ones with a timezone.

Either way proper date parsing & timezone support is needed, so I don't see any other good way out of it, unless you want to make tzinfo optional for Literal().toPython()

Comment 8 by gromgull
The way Jena does this is to fall back on Java - and java will assign the default timezone of the current locale to timestamps without TZ data. This of course leads to funny bugs that are hard to track down, if python really throws an exception that might be better.

In the end I guess there is no pleasant solution - programming with timezones is meant to be like a character building punishment.

Comment 9 by gromgull
Working on applying this patch there is a small issue - we currently use distutils (i.e. the python bundled library for describing the project), not setuptools.

Distutils lets you say that other packages are "required", but wont do anything to get them. To actually have python setup.py INSTALL the dependencies using easy_install you need to use setuptools.

And we actually went the other way not long ago: http://code.google.com/p/rdflib/issues/detail?id=114

:)

So, either we reintroduce setuptools - or we leave the dependency documented in the wiki/README/setup.py and let people install it themselves.

I did no think setuptools was such a liability - anyone with thoughts?

Comment 10 by christop...@gmail.com
What's the state of disutils2 and a backport to Python2 ?

Comment 11 by gerhard.weis@gmail.com
Setuptools is not a critical component of isodate. I guess I can make the dependency on setuptools optional.
If you really want to integrate it, I am happy to do that.

Regarding the timezones. I'll have a think about it. Maybe it makes sense to make the "empty TZ behaviour" configurable in some way. (but in general, I prefer to have proper time zoneing).

cheers

Comment 12 by gjhigg...@gmail.com
Fixed in changeset 6c8b1ba26686