Implement date & time literals via isodate

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by christop...@gmail.com on 22 Apr 2011 at 3:02

Attachments:

• depend_on_isodate_for_dt.diff

[GoogleCodeExporter]

Thanks!

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

Original comment by gromgull on 9 May 2011 at 11:39

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by gromgull on 9 May 2011 at 11:42

[GoogleCodeExporter]

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.

Original comment by lindstr...@gmail.com on 12 May 2011 at 2:03

[GoogleCodeExporter]

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.

Original comment by christop...@gmail.com on 12 May 2011 at 9:08

[GoogleCodeExporter]

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 <module>
    from rdflib import __version__
  File "/tmp/rdflib/rdflib/__init__.py", line 64, in <module>
    from rdflib.term import URIRef, BNode, Literal, Variable
  File "/tmp/rdflib/rdflib/term.py", line 33, in <module>
    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

Original comment by christop...@gmail.com on 31 May 2011 at 9:23

[GoogleCodeExporter]

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

Original comment by danielmr...@gmail.com on 1 Jun 2011 at 1:40

[GoogleCodeExporter]

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()

Original comment by christop...@gmail.com on 3 Jun 2011 at 4:09

[GoogleCodeExporter]

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. 

Original comment by gromgull on 15 Jun 2011 at 2:36

[GoogleCodeExporter]

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? 

Original comment by gromgull on 15 Jun 2011 at 3:12

[GoogleCodeExporter]

What's the state of disutils2 and a backport to Python2 ?

Original comment by christop...@gmail.com on 15 Jun 2011 at 4:20

[GoogleCodeExporter]

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

Original comment by gerhard.weis@gmail.com on 12 Oct 2011 at 12:55

[GoogleCodeExporter]

Fixed in changeset 6c8b1ba26686

Original comment by gjhigg...@gmail.com on 13 Jan 2012 at 2:36

• Changed state: Verified